Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov <[email protected]>:
> 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