On 23.05.22 22:54, G. P. B. wrote:
I don't like this RFC as it introduces special coercion semantics for boolean *only* in a function (+ typed properties (well at least I hope it impacts typed properties)) context.The obvious other context is the logical one with conditional statements and/or boolean operators (&&, ||, etc.) where it is pretty typical to do if ($string) {} and use $string as a boolean value. Having this be true in some contexts and false in others, depending on the content of the string is far from ideal. However, implicit coercion to bool can also arise when doing comparisons where one of the operands is null or bool. In this case which semantics should be used?
The problem is that coercion to a typed boolean is not the same as checking an expression for truthiness. It is somewhat related, but when there is a coercion to a typed boolean only scalar values can be coerced, which makes a big difference. Something like if (['']) is basically the same as if ([''] == true) which is why I call it checking for truthiness. Yet $obj->booleanProperty = ['']; will lead to a type error. So there is a clear difference there already. I also think the expectation is a different one - something like if ($string) is, as far as I have seen, most often used to check if a string it not empty. Yet if you do $obj->booleanProperty = $string; you then seem to specifically want to end up with a boolean type, not do a fuzzy check for truthiness. To me that is a very different situation where I actually find the current behavior surprising, in that is does not matter at all what scalar value I give a typed boolean, it will be happy with anything, and if it was a long string that was converted to boolean, you do possibly lose information. That can easily happen if someone changes a property from a string to boolean, but still assigns it a string somewhere. As soon as you use operators like && or || the intention becomes clearer again: $obj->booleanProperty = $string && $string2; There you are not passing the string directly to a boolean property, you are checking an expression, and you can even do $obj->booleanProperty = $array && $array2; // cannot pass an array to a boolean, but you can check an array (or two) for truthiness / not being empty
Can this prevent bugs, for sure, but within the function context we already have a tool to deal with these sorts of issues with strict_types.
But could you not argue the same for integers too? Why when you pass a string to an int parameter does it check if it is numeric, and not auto-coerce "hello" to 0? That is different behavior too, and one can use strict_types or explicit coercions instead. My argument is not that the proposal in this RFC is somewhat elegant or solves deep-rooted issues in the language. Similar to the numeric checks for int parameters I am interested in this for purely practical reasons. If somewhere in your application the integer -376 is passed to a boolean property (and coerced to true), would you not rather know about it? Is it not likely a bug, or at least an oversight? Would it not be easier on developers to know that only 7 scalar values are considered "unambigous" when passing to a typed boolean, and that they would be informed if they pass something else? I already rewrote the passage about raising this to a TypeError, where I state that this should be determined later when there is sufficient experience with these deprecation notices, and for me that is not really urgent - if this just remains an unintrusive deprecation notice for the next 10 years that would be fine with me. But I am convinced this will be a useful notice in many applications, where bugs can be found that otherwise would have stayed hidden for a very long time. I appreciate your feedback, and if I can improve anything about the RFC I am open to ideas. I think your RFCs for the type system have made PHP a much better language, and you seem to think about the big picture of the types in PHP, which is important for the language. This RFC might seem like a niche specific change and it does not affect much of PHP itself, but to me that could be what makes it a useful addition - if it mainly reveals bugs in applications, couldn't that be enough of a reason in favor of it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
