Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117519
Message-ID: <eed7bf5f-572f-11a4-51cd-542737cdacef@gmx.net>
Date: Mon, 11 Apr 2022 21:08:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
 <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
In-Reply-To: <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: a.leathley@gmx.net (Andreas Leathley)

On 11.04.22 20:22, Craig Francis wrote:
> Just take NULL to String coercion as an example, the documentation
> clearly
> and simply says =E2=80=9Cnull is always converted to an empty string=E2=
=80=9D, this needs
> to be updated to end with "... except when being passed to a function, i=
n
> which case NULL will result in a Type Error" (I think that's "broken and
> inconsistent").

You are taking parts of the documentation out of context, and omitting
the start of the whole "Converting to string" section:

"A value can be converted to a string using the (string) cast or the
strval() function. String conversion is automatically done in the scope
of an expression where a string is needed. This happens when using the
echo or print functions, or when a variable is compared to a string. The
sections on Types and Type Juggling will make the following clearer."

In the same section it is also defined how resources and arrays get
converted to strings. Following your argument, you should be able to
pass arrays and resources to a string parameter because there is a clear
definition in the documentation of what then happens.

I unfortunately really don't like the direction of your RFC, because I
see null as a real type and because it increases the divide between
strict_types and not using strict_types. I have never used strict_types
- in modern PHP code I find it unnecessary, if you use parameter,
property and return types. I am glad PHP has decreased the difference
between using strict_types or not, so your direction of trying to
increase the difference seems like the wrong way to go. Ideally I would
rather want to see a future where strict_types can be removed/reconciled.