> 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
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 "turn off" the
On Wed, 29 Dec 2021 at 17:42, Vincent Langlet
wrote:
> 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'
On Wed, 29 Dec 2021, 15:42 Vincent Langlet,
wrote:
>
> I recently discovered that an array was automatically casting
> numeric-string keys to int if it was possible.
>
Having had to track down bugs numerous times over the years, I completely
agree this is unexpected behaviour, and would be in
On 3 January 2022 16:07:53 GMT, Chase Peeler wrote:
>My mistake, I thought it did get casted. Still, I think you add a lot of
>complexity because you'll need to keep track of whether or not a key was a
>string or not. There is no guarantee that all numeric keys were originally
>a string:
>[ "1"
On Mon, Jan 3, 2022 at 10:48 AM Rowan Tommins
wrote:
> On 3 January 2022 15:41:48 GMT, Chase Peeler
> wrote:
> >But "001" casted to 1 will then get casted back to "1" not "001".
>
> "001" would not be cast to an integer in this context:
> https://3v4l.org/gGFHJ
>
>
My mistake, I thought it did
On 3 January 2022 15:41:48 GMT, Chase Peeler wrote:
>But "001" casted to 1 will then get casted back to "1" not "001".
"001" would not be cast to an integer in this context: https://3v4l.org/gGFHJ
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To
On Sun, Jan 2, 2022 at 7:05 AM Rowan Tommins
wrote:
> On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov wrote:
> >
> >I just gave an example of what at the moment can cause an exception in
> any application that is based on the PSR. It is enough to send the header
> "0: Farewell to the server".
I've sent a few emails to unsubscribe. Please remove me from this list. I'm
tired of these fucking emails about a dead language
On Sat, Jan 1, 2022, 8:41 AM Rowan Tommins wrote:
> On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> > I support this behavior fix because in its current form, due to a
On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov wrote:
>
>I just gave an example of what at the moment can cause an exception in any
>application that is based on the PSR. It is enough to send the header "0:
>Farewell to the server". In some cases (for example, as is the case with
On Sun, 2 Jan 2022 at 06:20, Michael Morris wrote:
>
> On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov wrote:
>
> >
> > >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
> > rowan.coll...@gmail.com>:
> > >
> > >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> > >> I support this behavior
>Воскресенье, 2 января 2022, 8:20 +03:00 от Michael Morris :
>
>On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov < n...@xakep.ru > wrote:
>
>>
>> >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
>> rowan.coll...@gmail.com >:
>> >
>> >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
>>
On Sat, Jan 1, 2022 at 9:20 PM Michael Morris wrote:
> I leave the decision making to the maintainers and contribs who do the
> actual work. Hell, I personally don't even use PHP that much these days
> having gotten a job where I focus on writing Cucumber tests in JavaScript
> that run on
On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov wrote:
>
> >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
> rowan.coll...@gmail.com>:
> >
> >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> >> I support this behavior fix because in its current form, due to a
> similar problem
>Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins
>:
>
>On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
>> I support this behavior fix because in its current form, due to a similar
>> problem (almost?), all PSR-7 implementations contain bugs that violate
>> RFC7230 (section 3.2:
>>
On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
I support this behavior fix because in its current form, due to a similar problem (almost?), all PSR-7
implementations contain bugs that violate RFC7230 (section
3.2:https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, physically, by
>Пятница, 31 декабря 2021, 10:20 +03:00 от Christian Schneider
>:
>
>Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov < n...@xakep.ru >:
>> I support this behavior fix because in its current form, due to a similar
>> problem (almost?), all PSR-7 implementations contain bugs that violate
>>
Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov :
> I support this behavior fix because in its current form, due to a similar
> problem (almost?), all PSR-7 implementations contain bugs that violate
> RFC7230 (section 3.2:
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus,
>Среда, 29 декабря 2021, 18:42 +03:00 от Vincent Langlet
>:
>
>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
On Thu, Dec 30, 2021 at 5:54 PM Vincent Langlet <
mr.vincent.lang...@gmail.com> wrote:
> Would you still consider this as a massive BC break if
> - The type of the key don't change anymore i.e. array_search(0, ['10' =>
> 0]) will be '10' and not 10.
> - $array[10] still return $array[10] ??
> 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
Hi!
I don't think this behavior should be considered as "normal" and would like
to propose to change this for PHP 9, as it's a BC-break. To me it can and
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
> 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
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 cause more work than
On Wed, Dec 29, 2021 at 4:42 PM Vincent Langlet
wrote:
> 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
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
26 matches
Mail list logo
