> De : Brian Moon [mailto:br...@moonspot.net]
>
> I agree here with Benjamin. The thing I have wanted in user land for
> years is to be able to build a user land function that worked the way
> internal functions do in terms of type checking without having to build
> my own type checking system. Having internal functions convert null to a
> scalar and not having user land do the same creates an inconsistency.
> For example, sometimes you want to wrap/extend an internal function (you
> see it a lot with json* to do encoding checking). I can't reliably take
> the same input to my user land wrapper that I can send to the internal
> function. I would prefer to see the same rules apply to internal and
> user land.
It would be better, yes. Unfortunately, accepting or refusing null to scalar in
both is difficult. If we disable null to scalar, we potentially generate a lot
of deprecation messages for existing code calling internal functions this way.
If we enable null to scalar, we create massive future inconsistencies now and
in the future. An example :
Function foo(): string {} // OK because returns null and null accepted as
string.
My opinion, but that's only mine, is that I would favor deprecating null to
scalar, even for internal functions. It would add deprecation messages but we'd
end up with a cleaner code.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
