Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121648
Message-ID: <0fe42819-e4dd-4329-b834-ed3295167e56@gmail.com>
Date: Fri, 10 Nov 2023 20:00:50 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: PHP Internals <internals@lists.php.net>
References: <CAFv4g+EqzB7whakuN-sr6YL2ih9xhHPzCsvTsEgJKMXBh9H9wQ@mail.gmail.com>
 <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk>
 <049d4758-def2-4a29-9e02-afa61e5b977e@gmail.com>
 <D02BC80D-89A4-4C2D-AF2E-2A96ADB45CA0@craigfrancis.co.uk>
Content-Language: en-GB
In-Reply-To: <D02BC80D-89A4-4C2D-AF2E-2A96ADB45CA0@craigfrancis.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Passing null to parameter
From: rowan.collins@gmail.com (Rowan Tommins)

On 10/11/2023 11:29, Craig Francis wrote:
> strict_types=1 enables strict type checking


While it's not exactly false, this statement is misleading in a really 
important way. That's not your fault, it's just that "strict_types" is, 
in hindsight, a really terrible name.

If I had a time machine (and a lot of patience to wade back into the 
debate), I would advocate naming the modes as follows:

* declare(scalar_params=coerce)
* declare(scalar_params=assert)


This would have made several things clearer.

1) Although asserting a type is in a sense "more strict" than coercing 
it, the "coerce" mode actually rejects more inputs than an explicit cast 
would.

2) The settings were never intended as a change to "the type system"; 
they don't change the behaviour of anything other than certain arguments 
passed into functions.

3) They only change the behaviour of a small number of new type keywords 
added to the language at that time: "int", "float", "string", and 
"bool". It governs the way these types interact with each other, and not 
anything about any other type.

Most relevantly for this discussion, that list does not include "null". 
At the time, the language already had type declarations on parameters 
for "array" and class/interface names, and those already disallowed null 
values. Note that this isn't a given, as many languages treat "null" as 
a valid value for any object type; recent developments in C# suggest PHP 
got it right for once by disallowing that from the start.


> I never understood why NULL was considered a complex value like a 
> class/callable/array, when it's more like a simple bool/int/float/string


I think you are misreading the quoted passage. It's not saying that null 
is similar to the complex types, it's saying that the handling of null 
values should be consistent between parameters marked with those 
keywords, and parameters marked with the new keywords "int", "float", 
"string", and "bool".


In actual fact, we could probably have narrowed the scope of the setting 
even further, because there are two cases that most people care about:

* coercing int to and from float (which is allowed in both modes anyway)
* coercing string to and from int or float (e.g. getting an ID or a 
price from a URL or API response)

So maybe we could have had:

* declare(numeric_params=coerce)
* declare(numeric_params=assert)


That would make it even clearer that the question of whether trim(null) 
is a meaningful operation is a completely separate debate than anything 
that the declare() covers.

Wherever it is used, "null" is a confusing and often controversial 
concept. In different contexts, it is used for different things, and has 
different ideal behaviours. It's a whole debate on its own, and bringing 
in other types of coercion just confuses the conversation.


Regards,

-- 
Rowan Tommins
[IMSoP]