Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122718
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------s0G8oWXfn8281z09TBLHBJWn"
Message-ID: <a1b87065-7b5b-442b-9d7a-26a6c8e0b5ec@rwec.co.uk>
Date: Thu, 21 Mar 2024 20:36:24 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Proposal: AS assertions
To: internals@lists.php.net
References: <CAPzBOBMGe=kWWiJYGLG02qxh+2Pe5yTqodhGtAE3LjdAPmkQUw@mail.gmail.com>
 <efbffe5a-f57a-42e4-8e0c-b25ab2c441fc@rwec.co.uk>
 <CAPzBOBM4b5c=hWgcj6uBgK3Lb65X56T-bhGHVGhma_YnCCJuoQ@mail.gmail.com>
 <CAPzBOBM8dmP5e-N4WXgM+7xbBYx7b=1DyPyJuV5O6QHX2F2s0w@mail.gmail.com>
 <3F78A125-1946-42E2-A4F5-A2B282BE2107@rwec.co.uk>
 <CAPzBOBPDVE-xtQoFUOXchwNAo_iJTGs=RKcnoq1mOtKF70eeLA@mail.gmail.com>
 <2d7ec203-6e80-445c-94f4-d29ef58743b1@rwec.co.uk>
 <CAPzBOBOqNT17CRiDsw78GH647xM09z4Y4HpSvM55RXoS-BWfKA@mail.gmail.com>
 <40d5c22f-5c06-403d-afc2-84c202277a29@rwec.co.uk>
 <CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------s0G8oWXfn8281z09TBLHBJWn
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 21/03/2024 19:03, Robert Landers wrote:
> I suppose we are taking this from different viewpoints, yours appears
> to be more of a philosophical one, whereas mine is more of a practical
> one.


My main concern is consistency; which is partly philosophical, but does 
have practical impact - the same syntax meaning the same thing in 
different contexts leads to less user confusion and fewer bugs.

But I also think there are real use cases for "error on anything other 
than either Foo or null" separate from "give me a null for anything 
other than Foo".

> $x = $a as null;
>
> (or any other value, such as true|false) appears to have no practical
> purpose in this particular case.


There's plenty of possible pieces of code that have no practical 
purpose, but that on its own isn't a good reason to make them do 
something different.

"null" as a standalone type (rather than part of a union) is pretty much 
always pointless, and was forbidden until PHP 8.2. It's now allowed, 
partly because there are scenarios involving inheritance where it does 
actually make sense (e.g. narrowing a return type from Foo|null to 
null); and probably also because it's easier to allow it than forbid it.


That's not really what we're talking about anyway, though; we're talking 
about nullable types, or null in a union type, which are much more 
frequently used.



> Further, reading "$x =
> $a as null", as a native English speaker, appears to be the same as
> "$x = null".


Well, that's a potential problem with the choice of syntax: "$x = $a as 
int" could easily be mistaken for "cast $a as int", rather than "assert 
that $a is int".

If you spell out "assert that $a is null", or "assert that $a is 
int|null", it becomes very surprising for 'hello' to do anything other 
than fail the assertion.


> As I mentioned in the beginning, I see this mostly being used when
> dealing with mixed types from built-in/library functions, where you
> have no idea what the actual type is, but when you write the code, you
> have a reasonable expectation of a set of types and you want to throw
> if it is unexpected.


My argument is that you might have a set of expected types which 
includes null, *and* want to throw for other, unexpected, values. If 
"|null" is special-cased to mean "default to null", there's no way to do 
that.


> Right now, the best way to do that is to simply
> set a function signature and pass the mixed type to the function to
> have the engine do it for you


And if you do that, then a value of 'hello' passed to a parameter of 
type int|null, will throw a TypeError, not give you a null.

As I illustrated in my last e-mail, you can even (since PHP 8.2) have a 
parameter of type null, and get a TypeError for any other value. That 
may not be useful, but it's entirely logical.


> It makes more sense, from a practical programming
> point-of-view, to simply return the value given if none of the types
> match.

This perhaps is a key part of our difference: when I see 
"int|bool|null", I don't see any "value given", just three built-in 
types: int, which has a range of values from PHP_INT_MIN to PHP_INT_MAX; 
bool, which has two possible values "true" and "false"; and null, which 
has a single possible value "null".

So there are 2**64 + 2 + 1 possible values that meet the constraint, and 
nothing to specify that one of those is my preferred default if given 
something unexpected.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------s0G8oWXfn8281z09TBLHBJWn
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 21/03/2024 19:03, Robert Landers
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com"><span
      style="white-space: pre-wrap">
</span>
      <pre class="moz-quote-pre" wrap="">I suppose we are taking this from different viewpoints, yours appears
to be more of a philosophical one, whereas mine is more of a practical
one.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>My main concern is consistency; which is partly philosophical,
      but does have practical impact - the same syntax meaning the same
      thing in different contexts leads to less user confusion and fewer
      bugs.</p>
    <p>But I also think there are real use cases for "error on anything
      other than either Foo or null" separate from "give me a null for
      anything other than Foo".<br>
    </p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
cite="mid:CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
$x = $a as null;

(or any other value, such as true|false) appears to have no practical
purpose in this particular case. </pre>
    </blockquote>
    <p><br>
    </p>
    <p>There's plenty of possible pieces of code that have no practical
      purpose, but that on its own isn't a good reason to make them do
      something different.</p>
    <p>"null" as a standalone type (rather than part of a union) is
      pretty much always pointless, and was forbidden until PHP 8.2.
      It's now allowed, partly because there are scenarios involving
      inheritance where it does actually make sense (e.g. narrowing a
      return type from Foo|null to null); and probably also because it's
      easier to allow it than forbid it.<br>
    </p>
    <p><br>
    </p>
    <p>That's not really what we're talking about anyway, though; we're
      talking about nullable types, or null in a union type, which are
      much more frequently used.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Further, reading "$x =
$a as null", as a native English speaker, appears to be the same as
"$x = null".</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Well, that's a potential problem with the choice of syntax: "$x =
      $a as int" could easily be mistaken for "cast $a as int", rather
      than "assert that $a is int".</p>
    <p>If you spell out "assert that $a is null", or "assert that $a is
      int|null", it becomes very surprising for 'hello' to do anything
      other than fail the assertion.<br>
    </p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
cite="mid:CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">As I mentioned in the beginning, I see this mostly being used when
dealing with mixed types from built-in/library functions, where you
have no idea what the actual type is, but when you write the code, you
have a reasonable expectation of a set of types and you want to throw
if it is unexpected.
</pre>
    </blockquote>
    <p><br>
    </p>
    <p>My argument is that you might have a set of expected types which
      includes null, *and* want to throw for other, unexpected, values.
      If "|null" is special-cased to mean "default to null", there's no
      way to do that.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAPzBOBOFydun_SNtkJ0P+hj88R4P=ocz3Sc-j+QiSk_g4U5s4Q@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Right now, the best way to do that is to simply
set a function signature and pass the mixed type to the function to
have the engine do it for you</pre>
    </blockquote>
    <p><br>
    </p>
    <p>And if you do that, then a value of 'hello' passed to a parameter
      of type int|null, will throw a TypeError, not give you a null.</p>
    <p>As I illustrated in my last e-mail, you can even (since PHP 8.2)
      have a parameter of type null, and get a TypeError for any other
      value. That may not be useful, but it's entirely logical.<br>
    </p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">It makes more sense, from a practical programming
point-of-view, to simply return the value given if none of the types
match.</pre>
      </blockquote>
      <br>
    </p>
    <p>This perhaps is a key part of our difference: when I see
      "int|bool|null", I don't see any "value given", just three
      built-in types: int, which has a range of values from PHP_INT_MIN
      to PHP_INT_MAX; bool, which has two possible values "true" and
      "false"; and null, which has a single possible value "null".</p>
    <p>So there are 2**64 + 2 + 1 possible values that meet the
      constraint, and nothing to specify that one of those is my
      preferred default if given something unexpected.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------s0G8oWXfn8281z09TBLHBJWn--