On Mon, 7 Feb 2022 at 09:34, Christian Schneider <cschn...@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
