On Wed, Mar 2, 2022 at 4:17 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Wed, Mar 2, 2022, at 8:00 AM, Craig Francis wrote: > > On Wed, 2 Mar 2022 at 12:26, Dik Takken <dik.tak...@gmail.com> wrote: > > > >> So, to get this crystal clear, this is my understanding of what you are > >> proposing for passing null to a non-nullable function parameter > >> (hopefully my ASCII art will come through ok): > >> > >> > >> which | strict_types | PHP 8.0 | PHP 8.1 | PHP 9 > >> ----------|---------------|------------|------------|---------- > >> user | 1 | TypeError | TypeError | TypeError > >> internal | 1 | TypeError | TypeError | TypeError > >> user | 0 | TypeError | TypeError | coerced > >> internal | 0 | coerced | Deprecated | coerced > >> > >> Is this correct? > >> > > > > > > Yes, that's correct... although I'd be doing this for 8.2, to avoid > > TypeError exceptions being introduced for non `strict_types` scripts in > 9.0. > > > > This is based on the feedback from the quiz and here; so type coercion > from > > NULL would continue to work, like coercion from the other variable types > > (string/int/float/bool). > > > > Craig > > Null is not an empty string. Null is not a string. Null is not 0. Null > is not an integer. > > The clear trend of the language is toward more type strictness. Going > back on that is a bad idea. Furthermore, increasing the delta between weak > and strict mode only serves to bifurcate the language and add one more > thing that people have to think about when they move from one file to > another; the language behaves differently depending on what file you're > in. That's already a cognitive overhead. Don't add to it. > > I am firmly -1 on weakening the type system, even if "weak mode". > This sounds like a good approach as well, not weakening the type system but, even more, it might be good to strengthen it, even if we are talking about strict_types=0. What bothers me a bit is why should strlen(false) be a valid method call but strlen(null) not so much. I think this is the inconsistency that should be fixed so the language would be easier to work with. And maybe the way to fix it is removing some coercions that happen right now and make little or no sense, strengthening the type system. The only coercion that is valid even with strict types: - int to float Coercions that should probably be kept as it makes sense in some cases: - int numeric string to int - float numeric string to float - int numeric string to float - int to string - float to string - bool to int - int to bool Coercions that should not be allowed, even if explicit type conversion should be still kept: - float or float numeric string to int (already deprecated in 8.1, not allowed starting with 9.0 by https://wiki.php.net/rfc/implicit-float-int-deprecate) - bool to string - string to bool - bool to float - float to bool Coercions that are already not working, even if explicit type conversion works and should continue to work: - non numeric string to int or float, starting with PHP 7.0 - not well formatted numeric string to int or float, starting with PHP 8.0 - null to int/float/bool/string, starting with PHP 7.0, if that can be considered a possible coercion I think that some RFC for deprecating some more cases would make the language a bit more consistent and reduce the coercion variation once we get to PHP 9.0 Alex
