Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123750
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------NF6z0xENH0vREv27zG2v0D0n"
Message-ID: <ce1de6a5-55ec-4850-8acf-ac5ba1ba95fe@rwec.co.uk>
Date: Sat, 22 Jun 2024 17:49:42 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: internals@lists.php.net
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <978b7177-8a22-41c0-94ce-d5539a2468c5@app.fastmail.com>
 <be98ada8-a0a5-4c7a-8dc4-a3f6becf861a@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <be98ada8-a0a5-4c7a-8dc4-a3f6becf861a@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------NF6z0xENH0vREv27zG2v0D0n
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 21/06/2024 19:29, Larry Garfield wrote:
> Valid points.  The line between validation and casting is a bit squishy,
>   as some casts can be forced (eg, string to int gives 0 sometimes), and
> others just cannot (casting to an object).  So would $a as
> array<~int> be casting, validating, or both?


I think my concern is that both "x is T" and "x as T" read naturally as 
*expressions*, where their main purpose is to evaluate to a result, and 
side-effects are exceptional.

 From that point of view, we can give intuitive meaning to the following:

- $foo is int => boolean; is $foo of type int?
- $foo is ~int => boolean; can $foo be "safely" cast to int?
- $foo as ~int => int; cast $foo to int (unless unsafe)

But then what does this mean?

- $foo as int => int; cast $foo to int if it's already an int !?

Similarly for a lot of other patterns:

- $foo as [int, int, int] => ??
- $foo as 3|5|null => ??


It seems like what's actually wanted here is something with an active 
verb, like "assert"; or a closed statement like "must be":

- $foo mustbe int; statement - if $foo is not an int, throw an error
- $foo mustbe ~int; statement - if $foo cannot be "safely" cast to int, 
throw an error
- $foo mustbe [int, int, int];
- $foo mustbe 3|5|null;


Then the "validate-and-cast" case is a completely separate feature, 
whose argument is a type, not a pattern (straw-man syntax):

- safe_cast($foo as int); cast $foo to int, unless unsafe
- safe_cast($foo as int|string); cast $foo to either int or string, 
using the same rules as parameters in mode 0
- safe_cast($foo as [int, int, int]); error, no such type to cast as


I think the uneasiness around binding vs matching against variables is 
related: if "$x is $y" is an expression, $y reads naturally as an input 
to that expression:

$arr = [ 123 ];
$fortyTwo = 42;

$arr is [ int ]; // true
$arr is [ 42 ]; // false
$arr is [ $fortyTwo ]; // false ?

As currently proposed, it's actually an *output*, and means something 
like this:

$arr is [ mixed{bind $fortyTwo} ] // true, with $fortyTwo set to 123 !


How about using "=" to mark that a variable name is being assigned to:

$arr is [ $fortyTwo ]; // false
$arr is [ $id=int ]; // true, and $id set to 123
$arr is [ $id= ]; // equivalent to [ $id=mixed ], i.e. bind $id without 
further constraining its value


So taking an example from the RFC:

$result = match ($p) is {
   Point{x: 3, y: 9, $z=} => "x is 3, y is 9, z is $z",
   Point{$z=, $x=, y: 4} => "x is $x, y is 4, z is $z",
   Point{x: 5, $y=} => "x is 5, y is $y, and z doesn't matter",
   Point{$x=, $y=, $z=} => "x is $x, y is $y, z is $z",
};


-- 
Rowan Tommins
[IMSoP]

--------------NF6z0xENH0vREv27zG2v0D0n
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/06/2024 19:29, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:be98ada8-a0a5-4c7a-8dc4-a3f6becf861a@app.fastmail.com">
      <pre>Valid points.  The line between validation and casting is a bit squishy,
 as some casts can be forced (eg, string to int gives 0 sometimes), and 
others just cannot (casting to an object).  So would $a as 
array&lt;~int&gt; be casting, validating, or both? </pre>
    </blockquote>
    <p><br>
    </p>
    <p>I think my concern is that both "x is T" and "x as T" read
      naturally as *expressions*, where their main purpose is to
      evaluate to a result, and side-effects are exceptional.</p>
    <p>From that point of view, we can give intuitive meaning to the
      following:</p>
    <p>- $foo is int =&gt; boolean; is $foo of type int?<br>
      - $foo is ~int =&gt; boolean; can $foo be "safely" cast to int?<br>
      - $foo as ~int =&gt; int; cast $foo to int (unless unsafe)<br>
    </p>
    <p>But then what does this mean?</p>
    <p>- $foo as int =&gt; int; cast $foo to int if it's already an int
      !?</p>
    <p>Similarly for a lot of other patterns:</p>
    <p>- $foo as [int, int, int] =&gt; ??<br>
      - $foo as 3|5|null =&gt; ??<br>
    </p>
    <p><br>
    </p>
    <p>It seems like what's actually wanted here is something with an
      active verb, like "assert"; or a closed statement like "must be":<br>
    </p>
    <p>- $foo mustbe int; statement - if $foo is not an int, throw an
      error<br>
      - $foo mustbe ~int; statement - if $foo cannot be "safely" cast to
      int, throw an error<br>
      - $foo mustbe [int, int, int];<br>
      - $foo mustbe 3|5|null;<br>
    </p>
    <p><br>
    </p>
    <p>Then the "validate-and-cast" case is a completely separate
      feature, whose argument is a type, not a pattern (straw-man
      syntax):</p>
    <p>- safe_cast($foo as int); cast $foo to int, unless unsafe<br>
      - safe_cast($foo as int|string); cast $foo to either int or
      string, using the same rules as parameters in mode 0<br>
      - safe_cast($foo as [int, int, int]); error, no such type to cast
      as</p>
    <p><br>
    </p>
    <p>I think the uneasiness around binding vs matching against
      variables is related: if "$x is $y" is an expression, $y reads
      naturally as an input to that expression:<br>
    </p>
    <p>$arr = [ 123 ];<br>
      $fortyTwo = 42;<br>
    </p>
    <p>$arr is [ int ]; // true<br>
      $arr is [ 42 ]; // false<br>
      $arr is [ $fortyTwo ]; // false ?</p>
    <p>As currently proposed, it's actually an *output*, and means
      something like this:</p>
    <p>$arr is [ mixed{bind $fortyTwo} ] // true, with $fortyTwo set to
      123 !<br>
    </p>
    <p><br>
    </p>
    <p>How about using "=" to mark that a variable name is being
      assigned to:</p>
    <p>$arr is [ $fortyTwo ]; // false<br>
      $arr is [ $id=int ]; // true, and $id set to 123<br>
      $arr is [ $id= ]; // equivalent to [ $id=mixed ], i.e. bind $id
      without further constraining its value<br>
    </p>
    <p><br>
    </p>
    <p>So taking an example from the RFC:</p>
    <pre class="code php"><span class="kw1"></span>$result = match ($p) is {
  Point{x: 3, y: 9, $z=} =&gt; "x is 3, y is 9, z is $z",
  Point{$z=, $x=, y: 4} =&gt; "x is $x, y is 4, z is $z",
  Point{x: 5, $y=} =&gt; "x is 5, y is $y, and z doesn't matter",
  Point{$x=, $y=, $z=} =&gt; "x is $x, y is $y, z is $z",
};
</pre>
    <p></p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------NF6z0xENH0vREv27zG2v0D0n--