Re: RFC: Stop to automatically cast numeric-string to int when using them as arr ay-key

>Пятница, 31 декабря 2021, 10:20 +03:00 от Christian Schneider ><cschneid@cschneid.com>: >  >Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov < nesk@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 RFC7230 (section 3.2: >> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, >> physically, by the standard, all headers can have the name "0" (like «0: value»), but >> when stored inside implementations, it is converted to a string and a problem arises >> ($message->getHeaders() // returns array<int|string, string> instead of array<string, >> string>). >> >> To solve this problem without BC, it seems to me that Nikita's idea with «declares» >> is most suitable, like: >> ``` >> <?php >> declare(strict_types=1, strict_array_keys=1); >> >> $array["0"] = 42; // array(1) { string(1) "0" => int(42) } >> ``` > >I probably sound like a broken record but I'd strongly advise against it as it creates >language dialects which means a line like >$a["0"] = 42; >behaves differently depending on context, e.g. copying code from Stackoverflow might lead to >subtle bugs and reminds me way too much of the ini-settings magic_quotes_gpc. > >My take is that changing behavior is ok if it can go through a deprecation/warning phase but >that is IMHO not the case here. > >If people want to have different behavior I'd rather have a new type like >$a = new Dict; >$a["0"] = 42; >possibly with a short-hand for initialization. > >Regards, >- Chris > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: https://www.php.net/unsub.php     Yep =(   In any case, I don't see any other solutions to the problem yet... Well, perhaps adding the Map and Set objects like in ur example.   On the other hand, probably we can forget about the BC and still fix it in major release. I don't think that anyone really uses such functionality and this is part of the real business logic. This is what I personally would prefer. Then this will automatically fix all PSR-7 implementations, and I hope there is a lot of code where such a case with automatic type conversion is not taken into account.   -- Kirill Nesmeyanov