Hi, I can't refrain from replying again...
On Sat, May 7, 2022 at 1:30 PM Mel Dafert <m...@dafert.at> wrote: > > It is exactly user-defined functions that this RFC introduces breakage for. > The behaviour to throw on null in user-defined functions exists since PHP > 7.0, and is being relied on. Changing these now would introduce behaviour > changes > that are harder to find than new type errors. Indeed, that's why in the previous thread (https://externals.io/message/116752#117121) I suggested: """ Or maybe (if going directly from error to implicit coercion is deemed too "risky") the current TypeError in non-strict_types mode (when passing NULL to a user-defined function expecting a scalar) could first be "demoted" to some kind of Notice [who said E_STRICT] in 8.2 (along with reverting the Deprecation added in 8.1 for internal functions) and removed in 9.0? """ On Tue, May 10, 2022 at 1:02 AM Craig Francis <cr...@craigfrancis.co.uk> wrote: > > On 7 May 2022, at 22:11, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > > What about `int|float`? Which one would it be coerced to? > > Good question, > > Short answer; today, if you pass the string '4' to a function that uses > `int|float`, then it receives `int(4)`: > > [...] > > Longer answer... > > [...] > > That said, and back to your question about `int|float`, because the string > '4' is coerced to `int(4)`, I'd prefer NULL to be coerced to `int(0)`. Is there really need for debate here? https://wiki.php.net/rfc/union_types_v2#coercive_typing_mode already says: """ If the exact type of the value is not part of the union, then the target type is chosen in the following order of preference: 1. int 2. float 3. string 4. bool If the type both exists in the union, and the value can be coerced to the type under PHPs existing type checking semantics, then the type is chosen. Otherwise the next type is tried. """ (besides, a numeric string is not the best example, because there's an exception, e.g. the string '4.0' is coerced to `float(4.0)` rather than to `int(4)`). On Tue, May 10, 2022 at 1:13 AM Craig Francis <cr...@craigfrancis.co.uk> wrote: > > On 8 May 2022, at 12:38, Mark Randall <marand...@php.net> wrote: > > On 08/05/2022 11:48, Jordan LeDoux wrote: > >> This is not the case with null. If you use the unset() function on a > >> variable for example, it will var_dump as null *and* it will pass an > >> is_null() check *and* it will pass a $var === null *and* it will return > >> false for an isset() check. Null loses these qualities if it is cast to > >> *any* scalar. > > > > Fortunately the writing is on the wall for the undefined cases, but that > > doesn't take away from your argument. > > Yep, I agree, an exception for an undefined variable is probably fine... I'm > looking at variables specifically being set to to the NULL value, and how > that NULL value is coerced. No need for an exception, accessing an undefined variable already triggers a Warning and is going to throw an Error in PHP 9.0 (https://wiki.php.net/rfc/undefined_variable_error_promotion). PS: about "Java", it has nothing to do; Java type declaration `Foo` (where Foo is a class/interface) is equivalent to PHP `?Foo` (or `Foo|null`) i.e. implicit *nullability* (that you cannot even opt-out; the `@NonNull` annotation only works with SCA/IDE or AOP), the RFC discussed here is about implicit *coercion of null to scalar*. Regards, -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
