[5.7] Let \Illuminate\Support\Carbon support immutable datetimes.

[lucasmichot]

Let \Illuminate\Support\Carbon support immutable datetimes and return a Chonos instance.

---

This requires cakephp/chronos to be installed as set in the suggest section of composer.json.

[DaneEveritt]

Why is this a dev requirement if it is being used by the Carbon support class?

[lucasmichot]

For the tests

[DaneEveritt]

So what happens when someone doesn't install chronos and then calls Carbon::immutable()?

[lucasmichot]

This won't work as (see PR description). Not everyone wants to use cakephp/chronos and immutable datetimes. The choice is given to the developer, so the reason why this is set in suggest

[devcircus]

A good middle ground. I'd like to see chronos, or an immutable friendly library, eventually replace carbon, but this may work.

[kylekatarnls]

Carbon 2 will come with the immutable support and a isImmutable which can be a bit confusing with this one (also planned toImmutable). It seems to me like a toChronos() would be less misleading.

Moreover, rather than mix the both libraries, I would suggest a setting here for example: https://github.com/laravel/laravel/blob/master/config/app.php#L176 to set the date library to Chronos, jenssegers/date or anything.

[kylekatarnls]

immutable() returns a MutableDateTime?

[taylorotwell]

Eh, not sure I really want to mix things up like that, especially with Carbon 2 supporting immutable dates. @kylekatarnls what is the ETA for Carbon 2?

[kylekatarnls]

August the 15 for a beta seems realistic, an alpha sooner, then a stable and documented release would go out for the beginning of September.

The dev branch version-2.0 is yet close to expected API, most of the work is now about cleaning up and migrating from PHP 5.3 to PHP 7.1 new minimum version using traits, typing, etc. so it can be used for tests (I use it in a personal Laravel project and it's going well).

I guess it will be a bit short for Laravel 5.7, but we'll sure be candidate for an implementation in Laravel 5.8.

I suppose it's not incompatible with some setting to customize the Date class method used for Laravel dates. I know it's not that simple but we could have some minimal interface a class should implement to be compatible with Laravel internal usage. I do not wish to be told we force Laravel users to use Carbon, so I could try to propose a PR for that.