On Mon, 11 Apr 2022 at 16:14, G. P. B. <george.bany...@gmail.com> wrote:
> But the implementation caused a Type Error when coercing NULL for everyone >> (even when not using *strict_types=1*), this seems more of an over-sight >> > is utterly wrong and was a conscious design choice based on the widely > accepted view that nullable by default like Java is a mistake and defeats > the purpose. > Bit hash... anyway, I've replaced that paragraph (it wasn't clear enough), I just wanted to note how developers not using `strict_types=1` would see it as an over-sight that coercion works for string/int/float/bool but not null (despite what the documentation says), and how it's introduced a type check (that they didn't ask for). I assume you're using `strict_types=1`, and will be unaffected by this, so with all due respect, I'm not considering how you view or use NULL, nor do I care what Java does, I'm simply focused on how most developers use NULL in PHP. "2. If the value can be coerced to the type requested by the hint without > data loss and without creation of likely unintended data - allow" Yep, as noted under the Documentation heading, and copying from the manual, “PHP will coerce values of the wrong type into the expected scalar type declaration if possible”... which it can, and does; for example, coercion to a string "null is always converted to an empty string". https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict https://www.php.net/manual/en/language.types.string.php [...] but this again brings us back to amending functions to have nullable > arguments, not a blanket change. > As noted in the Introduction, second paragraph, unfortunately this won't work (especially considering the ~335 parameters affected by this)... just taking `htmlspecialchars()` as the most simple example, I asked a few developers who use `strict_types=1`, and they did not want `$string` to be a nullable argument, because NULL being passed to this argument suggests there's a bug elsewhere in their code. This view was also reflected in the quiz (the names are links to view their answers): https://quiz.craigfrancis.co.uk/ The breaking change was justified and explained, and voted unanimously in > favour with 46 votes. > The burden of justification is now on your end. > My whole RFC is the justification, from the lack of discussion of the impact (where I will note that I am in favour of its intention of consistency), the roughly 85% of scripts that do not use `strict_types=1`, the almost certainly less than 33% developers who use static analysis, how tools do not and will not fix this problem, how this goes against the documentation, and all of the examples. Keep in mind, if you're using `strict_types=1`, great, you're not affected (I'm not either)... however, I work with quite a few developers, and it's causing them a lot of problems, and their current approach is to either disable the deprecation warnings, or to stay with 8.0, simply because they do not have the time to make the changes... I will note that one team has been trying to update their code base, it's about 6 months later, and they still keep adding `strval()` to silence these deprecation warnings (yeah, I know, not good, but it's the easy solution). changing the type system into a broken and inconsistent way, and reversing > a unanimously voted RFC needs strong justification. > I really appreciate your time to read my draft RFC, and I know there is no way I can change your mind, but can you explain how would this be "broken and inconsistent"? Just take NULL to String coercion as an example, the documentation clearly and simply says “null is always converted to an empty string”, this needs to be updated to end with "... except when being passed to a function, in which case NULL will result in a Type Error" (I think that's "broken and inconsistent"). Craig
