Re: Allowing NULL for some internal functions

On Mon, Feb 28, 2022, at 11:35 AM, Guilliam Xavier wrote: > On Mon, Feb 28, 2022 at 5:41 PM Dik Takken <dik.takken@gmail.com> wrote: > >> >> In my view, consistency between internal and userland functions brings a >> lot of value, and not only for the language itself. As soon as internal >> and userland become fully consistent it will become a lot easier to >> write "internal" functions in PHP rather than C. Not only will that make >> developing the standard library easier, it may also make the optimizer >> and JIT compiler more effective. The more consistency the better. >> > > Yes, and we see two possible ways to make them consistent w.r.t. handling > of null argument passed into scalar parameter: > > 1. implicit coercion by default, error with strict_types=1 > 2. error (independent of strict_types) > > AFAIK, internal functions have been doing 1 since like forever, but PHP 7.0 > chose 2 for userland functions when introducing scalar parameter type > declarations (see my previous message for history) and PHP 8.1 continued in > that direction by deprecating 1 for internal functions (and planning to > change them to 2 in PHP 9.0). > Call me devil's advocate, but is it too late to discuss revisiting past > decisions and consider changing direction towards 1 for userland functions > (esp. in implications of BC impact)? Under absolutely no circumstances should parameters become implicitly nullable. That way lies madness. And yes, coercing null to a magic zero-value is a form of implicit nullability. Absolutely not, under any circumstances. Bringing internal functions into line with user-space was the correct move. There may be internals functions that make sense to be nullable on their own right, on a case by case basis. We can evaluate that case by case. --Larry Garfield