Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125218
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------UEfVf3EgVoeaKqkAax1gWkvA"
Message-ID: <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
Date: Sun, 25 Aug 2024 16:31:46 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------UEfVf3EgVoeaKqkAax1gWkvA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 25/08/2024 14:35, Larry Garfield wrote:
> My other concern is the list of supported expression types.  I
> understand how the implementation would naturally make all of those
> syntactically valid, but it seems many of them, if not most, are
> semantically nonsensical.


I tend to agree with Larry and John that the list of operators should be 
restricted - we can always allow more in future, but restricting later 
is much harder.

A few rules that seem logical to me:

1) The expression should be reasonably guaranteed to produce the same 
type as the actual default.

- No casts
- No comparison operators, because they produce booleans from 
non-boolean input
- No "<=>". Technically, it has an integer result, but it's rare to use 
it as one, rather than a kind of three-value boolean
- No "instanceof"
- No "empty"

2) The expression should not have side effects (outside of exotic 
operator overloads).

- No "include", "require", etc
- No "throw"
- No "print"
- Borderline, but I would also say no "clone"

3) The expression should be passing additional information into the 
function, not pulling information out of it. The syntax shouldn't be a 
way to write obfuscated reflection, or invert data flow from callee to 
caller.

- No assignments.
- No ternaries with "default" on the left-hand side - "$foo ? $bar : 
default" is acting on local knowledge, but "default ? $foo : $bar" is 
acting on information the caller shouldn't know
- Same for "?:" and "??"
- No "match" with "default" as the condition or branch, for the same 
reason. "match($foo) { $bar => default }" is fine, match(default) { ... 
}" or "match($foo) { default => ... }" are not.

Note that these can be seen as aspects of the same rule: the aim of the 
expression should be to transform the default value into another value 
of the same type, not to pull it out and perform arbitrary operations 
based on it.


I believe that leaves us with:

- Arithmetic operators: binary + - * / % **, unary + -
- Bitwise operators: & | ^ << >>  ~
- Boolean operators: && || and or xor !
- Conditions with default on the RHS: $foo ? $bar : default, $foo ?: 
default, $foo ?? default, match($foo) { $bar => default }
- Parentheses: (((default)))


Even then, I look at that list and see more problems than use cases. As 
the RFC points out, library authors already worry about the maintenance 
burden of named argument support, will they now also need to question 
whether someone is relying on "default + 1" having some specific effect?

Maybe we should instead require justification for each addition:

- Bitwise | is nicely demonstrated in the RFC
- Bitwise & could probably be justified on similar grounds
- "$foo ? $bar : default" is discussed in the RFC
- The other "conditions with default on the RHS" in my shortlist above 
fit the same basic use case

Beyond that, I'm struggling to think of meaningful uses: "whatever the 
function sets as its default, do the opposite"; "whatever number the 
function sets as default, raise it to the power of 3"; etc. Again, they 
can easily be added in later versions, if a use case is pointed out.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------UEfVf3EgVoeaKqkAax1gWkvA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 25/08/2024 14:35, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com">
      <pre>My other concern is the list of supported expression types.  I 
understand how the implementation would naturally make all of those 
syntactically valid, but it seems many of them, if not most, are 
semantically nonsensical.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I tend to agree with Larry and John that the list of operators
      should be restricted - we can always allow more in future, but
      restricting later is much harder.</p>
    <p>A few rules that seem logical to me:</p>
    <p>1) The expression should be reasonably guaranteed to produce the
      same type as the actual default.<br>
    </p>
    <p>- No casts<br>
      - No comparison operators, because they produce booleans from
      non-boolean input<br>
      - No "&lt;=&gt;". Technically, it has an integer result, but it's
      rare to use it as one, rather than a kind of three-value boolean<br>
      - No "instanceof"<br>
      - No "empty"<br>
    </p>
    <p>2) The expression should not have side effects (outside of exotic
      operator overloads).</p>
    <p>- No "include", "require", etc<br>
      - No "throw"<br>
      - No "print"<br>
      - Borderline, but I would also say no "clone"<br>
    </p>
    <p>3) The expression should be passing additional information into
      the function, not pulling information out of it. The syntax
      shouldn't be a way to write obfuscated reflection, or invert data
      flow from callee to caller.<br>
    </p>
    <p>- No assignments.<br>
      - No ternaries with "default" on the left-hand side - "$foo ? $bar
      : default" is acting on local knowledge, but "default ? $foo :
      $bar" is acting on information the caller shouldn't know<br>
      - Same for "?:" and "??"<br>
      - No "match" with "default" as the condition or branch, for the
      same reason. "match($foo) { $bar =&gt; default }" is fine,
      match(default) { ... }" or "match($foo) { default =&gt; ... }" are
      not.<br>
    </p>
    <p>Note that these can be seen as aspects of the same rule: the aim
      of the expression should be to transform the default value into
      another value of the same type, not to pull it out and perform
      arbitrary operations based on it.</p>
    <p><br>
    </p>
    <p>I believe that leaves us with:</p>
    <p>- Arithmetic operators: binary + - * / % **, unary + -<br>
      - Bitwise operators: &amp; | ^ &lt;&lt; &gt;&gt;  ~<br>
      - Boolean operators: &amp;&amp; || and or xor !<br>
      - Conditions with default on the RHS: $foo ? $bar : default, $foo
      ?: default, $foo ?? default, match($foo) { $bar =&gt; default }<br>
      - Parentheses: (((default)))</p>
    <p><br>
    </p>
    <p>Even then, I look at that list and see more problems than use
      cases. As the RFC points out, library authors already worry about
      the maintenance burden of named argument support, will they now
      also need to question whether someone is relying on "default + 1"
      having some specific effect?</p>
    <p>Maybe we should instead require justification for each addition:</p>
    <p>- Bitwise | is nicely demonstrated in the RFC<br>
      - Bitwise &amp; could probably be justified on similar grounds<br>
      - "$foo ? $bar : default" is discussed in the RFC<br>
      - The other "conditions with default on the RHS" in my shortlist
      above fit the same basic use case<br>
    </p>
    <p>Beyond that, I'm struggling to think of meaningful uses:
      "whatever the function sets as its default, do the opposite";
      "whatever number the function sets as default, raise it to the
      power of 3"; etc. Again, they can easily be added in later
      versions, if a use case is pointed out.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------UEfVf3EgVoeaKqkAax1gWkvA--