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 > 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