> It'd not be just a BC break, it'd be an absolutely massive BC break that
> has a potential to break a ton of code and would be extremely hard to
> detect. This is not something that should be changed in an advanced
> version of the language.
>
Would you still consider this as a massive BC break
> On 29/12/2021 16:58, Lynn wrote:
> > While I'd love for this inconsistency to go away, I also know that this
> is
> > most likely such a big change that it causes months of work and broken
> code
> > because it relies on this behavior. It wouldn't surprise me if this
> > singular change would
Hi,
I recently discovered that an array was automatically casting
numeric-string keys to int if it was possible. For instance, the following
array:
$a = ['01' => '01', '10' => '10'];
Is not an array with the key '01' and '10' but instead consider the second
key as an int.
This has some
> On 6 January 2022 07:29:58 GMT, James Titcumb wrote:
> >Just thinking out loud, being able to identify an array type might be a
> way
> >forward here (using "syntax" already in use by static analysis tools in
> >docblocks, for familiarity), e.g.
> >
> >private array $property;
> >
> >This might
Hi,
When using json_encode or json_decode with the `JSON_THROW_ON_ERROR` flag,
`JsonException` might be thrown.
When using `new DateTime('foo')`, a generic `Exception` is thrown.
Incidentally, I wonder why it's not an `InvalidArgumentException` (but that
could be another debate).
But my main
Hi,
IMHO, the more meaningful cases of the RFC are missing :
round(float, precision: >= 0): int|float // only cast to float for int overflow
ceil(float): int|float // only cast to float for int overflow
floor(float): int|float // only cast to float for int overflow
Calling ceil or floor on
