Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117542
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <42D0A480-F262-4F72-9C4D-887762A8D800@gmail.com>
In-Reply-To: <42D0A480-F262-4F72-9C4D-887762A8D800@gmail.com>
Date: Tue, 19 Apr 2022 12:34:58 +0100
Message-ID: <CAFv4g+ELZ5ZA6zyDFHCJCM6vSy3MFTvEGS9=zo5ZM1izHQWuFw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000106ce405dd00458f"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000106ce405dd00458f
Content-Type: text/plain; charset="UTF-8"

On Sat, 16 Apr 2022 at 12:17, Rowan Tommins <rowan.collins@gmail.com> wrote:

> On 8 April 2022 18:34:52 BST, Craig Francis <craig@craigfrancis.co.uk>
> wrote:
> >I've written a new draft RFC to address the NULL coercion problems:
> >
> >https://wiki.php.net/rfc/null_coercion_consistency
>
>
> I'm sympathetic to the general problem you're trying to solve, but I'm not
> convinced by the argument that this is about consistency, because user
> defined functions have been consistently rejecting null for non-nullable
> parameters since PHP 7.0, and even before that for arrays and objects.



Thanks for looking at this Rowan.

I am open to discussing different solutions (this is my second attempt),
and any suggestions are welcome.

In regards to consistency, while I think my RFC does that, it's not my main
motivation for creating this RFC - which is to address the backwards
compatibility issues.

But to expand on consistency, I appreciate user defined functions (since
7.0) didn't coerce NULL, and I do want internal/user defined functions to
be consistent with each other (why I agree with the spirit of the original
RFC), it's just odd that string/int/float/bool can be coerced, but NULL
cannot be coerced in this context and can be in other contexts, e.g.

```
$i = 0;
$n = NULL;

if ($i == $n) { // Fine
}

print($i); // Fine
print($n); // Fine
printf('%s', $i); // Fine
printf('%s', $n); // Fine
echo 'ConCat ' . $i . $n; // Fine
echo htmlspecialchars($i); // Fine
echo htmlspecialchars($n . ''); // Fine
echo htmlspecialchars($n); // Bad???
```



Consistency is a good argument for small changes that eliminate unusual
> edge cases, but I think far-reaching changes should be able to stand on
> their own merits - regardless of whether it's consistent, do we want the
> language to work this way?
>


Good question, while I mention consistency, my focus is on backwards
compatibility, and how PHP has accepted NULL to these ~335 parameters
since, well, forever... my fear is that the upgrade to PHP 9 will be so
difficult (as noted with the lack of tooling to solve this), I'll be
auditing PHP code that's stuck on 8.x for many years to come.

https://twitter.com/mwop/status/1441044164880355342



To me, the main defence of type coercion is that PHP operates in a world
> full of strings - URLs are strings, HTTP requests are strings, and a lot of
> API responses are strings - so making it easy to work with strings like
> '42' as numbers makes a lot of sense. It's not clear to me that this
> extends to null.
>


Yep, PHP does work in a world of strings, and for simplicity
string coercion works fairly well... but I think I can include NULL in that
definition, because HTTP requests do not guarantee values have been
provided, where PHP (via filter_input) and frameworks (Laravel, Symfony,
CakePHP, CodeIgniter, etc), have used NULL to note when a value has not
been provided... and many developers have simply not cared about that
distinction (e.g. when passing to htmlspecialchars, trim, strlen,
preg_match, etc).



I think a large part of the problem here is that null can mean many
> different things in different contexts - "unknown", "not provided",
> "invalid input", "default", "not applicable", etc.
>
> These differences are subtle, but lead to different expectations of
> behaviour:
>
> - Treat null as a specific case with its own meaning, distinct from any
> other valid value. This is what explicitly nullable parameters and union
> types allow.
> - Treat null the same as any other out of range value, and raise an error.
> This is what happens in user-defined functions in PHP, and in built-in
> functions expecting non-scalar arguments. Compare also out of range actions
> like division by zero.
> - Treat null as a special state that propagates through expressions,
> because any operation with an unknown input has an unknown output. This is
> the approach to null taken by SQL, and by IEEE floating point with NaN. It
> is also the basis of the ?-> operator, and of things like Optional.map in
> Swift.
> - Treat null as a generic default value which can be filled in implicitly
> based on requirements. This is the interpretation currently taken by
> internal functions for scalar arguments, and what you are proposing to make
> standard. It is also, as you point out, the way PHP treats null in some
> other contexts, such as many operators.
>


Thank you, that's a really good explanation.

The developers I work with would assume the last definition, in the same
way they can pass in an integer to `urlencode()`, where they just don't
think about it being implicitly coerced into a string, it just works
(TM)... that's not to say the `strict_types=1` style of checking, and NULL
being treated as an invalid value, doesn't provide value for some
developers (but as shown in the stats, they are in the minority).



Interestingly, one of your examples mentions filter_input, which takes the
> "propagate" approach, and htmlspecialchars, which doesn't. It would often
> be more useful to retain the information that a value is null than to have
> it silently converted to an empty string as a side-effect of some other
> operation.



Those are interesting points.

I think `filter_input()` is a bit different, as it's a source of data (not
exactly propagating); whereas all of the other functions, they either
process that data (and return a sting, and do not propagate) or work with
it (e.g. preg_match and strcmp returning a bool, strlen returning an
integer, etc).

Retaining NULL is interesting, but it would be a new thing...



Perhaps it would be useful to have some function-call equivalent of the ?->
> operator. I'm not sure what this would look like for normal function calls,
> but it would be easy to add if we had a pipe operator, e.g.:
>
> If this was equivalent to htmlspecialchars($foo)
> $foo |> htmlspecialchars(...)
>
> Then this could be equivalent to ($foo === null ? null :
> htmlspecialchars($foo))
> $foo ?|> htmlspecialchars(...)
>


... adding that syntax might be useful in some contexts (when the developer
wants to make NULL easier to propagate); but that would be a new feature,
and I don't think it solves the backwards compatibility issue we currently
face, and what I'm trying to address in this RFC.



I'm not set against this RFC, but I'm not quite convinced by the case it
> makes, and think there may still be other options to explore.
>


I'm open to any suggestions, I just want to avoid the situation where Fatal
Type Errors happen seemingly randomly (as in, someone who has never used
type checks before, and they use NULL without any thought about it).

I'm even open to the idea of someone coming up with a tool to auto-update
existing code, but so far I've only heard people say that is the way it
should be done (with absolutely no detail on how it would even begin to
work).

I also cannot explain why NULL should be rejected, other than for those
developers who see NULL as an invalid value and also use
`strict_types=1`... as in, when a team of developers spends a few hundred
hours adding strval() everywhere, what does that actually achieve? what do
they tell the client? does it make the code easier to read? does it avoid
any bugs? or is it only for 8.1 compatibility?

Anyway, thanks again Rowan, I really appreciate your thoughts on this.

Craig

--000000000000106ce405dd00458f--