Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116992
MIME-Version: 1.0
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>
In-Reply-To: <7CCE6061-F5BD-4C10-8BD1-F5A2A994D5F6@cschneid.com>
Date: Mon, 7 Feb 2022 12:07:24 +0000
Message-ID: <CAFPFaMLFe7ZpD-EXg03NFh5CdL3mf9MxXTBstFxASBbo=3FYOA@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000324ada05d76c72b1"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: george.banyard@gmail.com ("G. P. B.")

--000000000000324ada05d76c72b1
Content-Type: text/plain; charset="UTF-8"

On Mon, 7 Feb 2022 at 09:34, Christian Schneider <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.
>
> 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.
>
> - Chris
>

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.

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.

The list of proposed functions is also excessive and just feels that any
function which raised a diagnostic during a test run on 8.1 was chugged
into it.
Let's look at an example taken from the document (
https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-change.md#output
)
- setcookie(name:string, *value:string*, expires_or_options:array|int,
*path:string*, *domain:string*, secure:bool, httponly:bool)
- setrawcookie(name:string, *value:string*, expires_or_options:array|int,
*path:string*, *domain:string*, secure:bool, httponly:bool)

I really do not see why for the path and the domain should *ever* accept
NULL, as if somehow that happens I would have some serious questions about
how you get that information.
However, there *might* be an argument to be made to make the value
parameter nullable. Although I would find this instance very questionable.

I'm not against in principle of marking certain parameters as nullable, but
it for sure should not be on a basis of using strict_types or not.

Best regards,

George P. Banyard

--000000000000324ada05d76c72b1--