Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116996
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_95E7DA14-AA98-456B-A9B4-0A98921F093D"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Mon, 7 Feb 2022 13:57:37 +0100
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+HvM5CPw6DNdsipYmZEb3zjWY2_Use4O+yfxAPBedzFUw@mail.gmail.com>
 <cmu-lmtpd-3262-1644222965-0@darkcity>
 <7CCE6061-F5BD-4C10-8BD1-F5A2A994D5F6@cschneid.com>
 <CAFPFaMLFe7ZpD-EXg03NFh5CdL3mf9MxXTBstFxASBbo=3FYOA@mail.gmail.com>
To: internals <internals@lists.php.net>
In-Reply-To: <CAFPFaMLFe7ZpD-EXg03NFh5CdL3mf9MxXTBstFxASBbo=3FYOA@mail.gmail.com>
Message-ID: <C484B937-5847-4779-91B7-93A81AB78DFF@cschneid.com>
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: cschneid@cschneid.com (Christian Schneider)

--Apple-Mail=_95E7DA14-AA98-456B-A9B4-0A98921F093D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 07.02.2022 um 13:07 schrieb G. P. B. <george.banyard@gmail.com>:
> On Mon, 7 Feb 2022 at 09:34, Christian Schneider =
<cschneid@cschneid.com <mailto:cschneid@cschneid.com>> wrote:
> > If a parameter expects a string, that is what it should be given, =
and its the callers' responsibility to ensure that is the case. If they =
fail to do so then it's an error just like any other.
>=20
> The decision to define e.g. strlen() as strlen(string $string) instead =
of strlen(?string $string) was arbitrary and I for one would prefer the =
loose definition.
>=20
> - Chris
>=20
> I'm not sure what you are getting on here? strlen() was always defined =
to only take a string and never was nullable in the first place.

Now this is a little bit misleading: Before 7.0 we did not have scalar =
type hints so the documentation of strlen(string $string) was somewhat =
lying, especially because back in those days the automatic type jugging =
from null to "" was used a lot.

> The RFC which is at the heart of this is the one to make internal =
functions and userland functions consistent.
> Therefore introducing a mechanism which makes only *some* functions =
special and weird is a complete no go for me.
> Either there is a (strong) case for the parameter to be nullable, and =
then it should be marked as such and not do weird shenanigans with =
regards to strict_types (which I dislike more and more by the second), =
or there is not.

So you are basically saying that we should discuss making it
	strlen(?string $string): int
which would be cleaner, I agree.

About the case having to be strong: I could also argue that you have to =
make a strong case on why null should not be allowed any more (any more =
as per implementation, not documentation) as it is a seizable BC.

There are other things which can go wrong with strlen() on a higher =
level (e.g. misuse with utf-8) and I would like to see a real world code =
where strlen(null) actually broke something while not generating any =
other error in the code path.

- Chris


--Apple-Mail=_95E7DA14-AA98-456B-A9B4-0A98921F093D--