Am 07.02.2022 um 13:07 schrieb G. P. B. <george.bany...@gmail.com>:
> On Mon, 7 Feb 2022 at 09:34, Christian Schneider <cschn...@cschneid.com
> <mailto: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.
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
