Am 07.02.2022 um 09:35 schrieb Mark Randall <marand...@php.net>: > On 07/02/2022 01:27, Craig Francis wrote: >> I know one person simply said this was a "terribl > idea", but I'm still >> waiting to hear any details on why. > > I understand your motivations in proposing them, but to my mind it goes > against the direction that PHP is developing, which I think is the right one, > where errors and likely errors result in stopping execution rather than > allowing it continue, potentially silently (dependent on error handling > settings).
I think some proposals for PHP are going too far with strictness so I very much like Crag's RFC. > If a parameter expects a string, that is what it should be given, and its the > callers' responsibility to ensure that is the case. If they fail to do so > then it's an error just like any other. The decision to define e.g. strlen() as strlen(string $string) instead of strlen(?string $string) was arbitrary and I for one would prefer the loose definition. I'm confident that any real world example would abort at an early enough stage to catch errors in your program, without something as basic as strlen() having to do the job while adding complexity for something as simple as "if (strlen($x)) ..". > IMHO reverting to "If it's a null we'll just pretend its a string" is > contrary to how the language should be progressing. > It sucks that it was ever allowed in the first place. I think we agree to disagree here ;-) > PHP has a long history of making descisions to try to make things 'just > work', and if history teaches us anything, its that we inevitably come to > regret these descisions down the line. PHP has a long history of being a concise, pragmatic language and there are many who do not regret this at all. Finding the right balance is key here. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
