Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117227
MIME-Version: 1.0
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+GDsq=w7qtSOVptEBiTTDZk2aeFCVGThVBR=0-xk=0oAA@mail.gmail.com>
 <983552d8-11f1-b5bc-fb82-148347982fda@gmx.de> <5494eaa7-2fa6-8364-9683-a2c8c9789d81@gmail.com>
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
 <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com> <CAFv4g+F0HOgCgeUyiG06qhxQnWbVCN2aaP=a2CJT9tkbMP7kLg@mail.gmail.com>
 <7fbed755-42e2-d023-285f-39863a97f297@gmx.de> <3665C848-B4C3-4528-AEFA-02C868748AA8@cschneid.com>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de> <CAFv4g+HPm+edmgnPAGwBk=4EJxj2can--iWfgtMasrYHk6pLww@mail.gmail.com>
 <4bff3f23-a3ec-4416-f44e-1f4f5d7e0caa@gmail.com> <CAFv4g+E159xoR4hxtsay-FamCSrJN+DmodvjzYGHcd1pQFsX+Q@mail.gmail.com>
 <2d06bc12-7d7e-4a88-b823-de64642381e6@www.fastmail.com>
In-Reply-To: <2d06bc12-7d7e-4a88-b823-de64642381e6@www.fastmail.com>
Date: Wed, 2 Mar 2022 23:42:03 +0200
Message-ID: <CAAwdEzDqkLb=LDNH=1TJHkuHq31DsWMaTZ-TbRuU0wxRLRT43A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000000d18e05d9432859"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000000d18e05d9432859
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 2, 2022 at 4:17 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Wed, Mar 2, 2022, at 8:00 AM, Craig Francis wrote:
> > On Wed, 2 Mar 2022 at 12:26, Dik Takken <dik.takken@gmail.com> wrote:
> >
> >> So, to get this crystal clear, this is my understanding of what you are
> >> proposing for passing null to a non-nullable function parameter
> >> (hopefully my ASCII art will come through ok):
> >>
> >>
> >> which     | strict_types  | PHP 8.0    | PHP 8.1    | PHP 9
> >> ----------|---------------|------------|------------|----------
> >> user      | 1             | TypeError  | TypeError  | TypeError
> >> internal  | 1             | TypeError  | TypeError  | TypeError
> >> user      | 0             | TypeError  | TypeError  | coerced
> >> internal  | 0             | coerced    | Deprecated | coerced
> >>
> >> Is this correct?
> >>
> >
> >
> > Yes, that's correct... although I'd be doing this for 8.2, to avoid
> > TypeError exceptions being introduced for non `strict_types` scripts in
> 9.0.
> >
> > This is based on the feedback from the quiz and here; so type coercion
> from
> > NULL would continue to work, like coercion from the other variable types
> > (string/int/float/bool).
> >
> > Craig
>
> Null is not an empty string.  Null is not a string.  Null is not 0.  Null
> is not an integer.
>
> The clear trend of the language is toward more type strictness.  Going
> back on that is a bad idea.  Furthermore, increasing the delta between weak
> and strict mode only serves to bifurcate the language and add one more
> thing that people have to think about when they move from one file to
> another; the language behaves differently depending on what file you're
> in.  That's already a cognitive overhead.  Don't add to it.
>
> I am firmly -1 on weakening the type system, even if "weak mode".
>

This sounds like a good approach as well, not weakening the type system
but, even more, it might be good to strengthen it, even if we are talking
about strict_types=0.

What bothers me a bit is why should strlen(false) be a valid method call
but strlen(null) not so much. I think this is the inconsistency that should
be fixed so the language would be easier to work with.
And maybe the way to fix it is removing some coercions that happen right
now and make little or no sense, strengthening the type system.

The only coercion that is valid even with strict types:
- int to float

Coercions that should probably be kept as it makes sense in some cases:
- int numeric string to int
- float numeric string to float
- int numeric string to float
- int to string
- float to string
- bool to int
- int to bool

Coercions that should not be allowed, even if explicit type conversion
should be still kept:
- float or float numeric string to int (already deprecated in 8.1, not
allowed starting with 9.0 by
https://wiki.php.net/rfc/implicit-float-int-deprecate)
- bool to string
- string to bool
- bool to float
- float to bool

Coercions that are already not working, even if explicit type conversion
works and should continue to work:
- non numeric string to int or float, starting with PHP 7.0
- not well formatted numeric string to int or float, starting with PHP 8.0
- null to int/float/bool/string, starting with PHP 7.0, if that can be
considered a possible coercion

I think that some RFC for deprecating some more cases would make the
language a bit more consistent and reduce the coercion variation once we
get to PHP 9.0

 Alex

--00000000000000d18e05d9432859--