Re: Allowing NULL for some internal functions

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. > > 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. 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