Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125220
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 17:54:48 +0200
To: internals@lists.php.net
Message-ID: <4dad8898-b6d3-4b1b-aa7c-bd8385857f11@app.fastmail.com>
In-Reply-To: <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: multipart/alternative;
 boundary=9722f6cc65404543a9bc6ca629deee85
From: rob@bottled.codes ("Rob Landers")

--9722f6cc65404543a9bc6ca629deee85
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Aug 25, 2024, at 17:31, Rowan Tommins [IMSoP] wrote:
> On 25/08/2024 14:35, Larry Garfield wrote:
>> My other concern is the list of supported expression types.  I=20
>> understand how the implementation would naturally make all of those=20
>> syntactically valid, but it seems many of them, if not most, are=20
>> semantically nonsensical.
>=20
>=20
> 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 late=
r is much harder.
>=20
> A few rules that seem logical to me:
>=20
> 1) The expression should be reasonably guaranteed to produce the same =
type as the actual default.
>=20
>=20
> - No casts
> - No comparison operators, because they produce booleans from non-bool=
ean input
> - No "<=3D>". 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"
>=20
> 2) The expression should not have side effects (outside of exotic oper=
ator overloads).
>=20
>=20
> - No "include", "require", etc
> - No "throw"
> - No "print"
> - Borderline, but I would also say no "clone"
>=20
> 3) The expression should be passing additional information into the fu=
nction, not pulling information out of it. The syntax shouldn't be a way=
 to write obfuscated reflection, or invert data flow from callee to call=
er.
>=20
>=20
> - No assignments.
> - No ternaries with "default" on the left-hand side - "$foo ? $bar : d=
efault" is acting on local knowledge, but "default ? $foo : $bar" is act=
ing on information the caller shouldn't know
> - Same for "?:" and "??"
> - No "match" with "default" as the condition or branch, for the same r=
eason. "match($foo) { $bar =3D> default }" is fine, match(default) { ...=
 }" or "match($foo) { default =3D> ... }" are not.
>=20
> Note that these can be seen as aspects of the same rule: the aim of th=
e expression should be to transform the default value into another value=
 of the same type, not to pull it out and perform arbitrary operations b=
ased on it.
>=20
>=20
>=20
> I believe that leaves us with:
>=20
>=20
> - Arithmetic operators: binary + - * / % **, unary + -
> - Bitwise operators: & | ^ << >>  ~
> - Boolean operators: && || and or xor !
> - Conditions with default on the RHS: $foo ? $bar : default, $foo ?: d=
efault, $foo ?? default, match($foo) { $bar =3D> default }
> - Parentheses: (((default)))
>=20
>=20
>=20
> Even then, I look at that list and see more problems than use cases. A=
s the RFC points out, library authors already worry about the maintenanc=
e burden of named argument support, will they now also need to question =
whether someone is relying on "default + 1" having some specific effect?
>=20
> Maybe we should instead require justification for each addition:
>=20
>=20
> - 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
>=20
> Beyond that, I'm struggling to think of meaningful uses: "whatever the=
 function sets as its default, do the opposite"; "whatever number the fu=
nction sets as default, raise it to the power of 3"; etc. Again, they ca=
n easily be added in later versions, if a use case is pointed out.
>=20
>=20
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]

Hi Rowan, you went through a lot of trouble to write this out, and the r=
easoning makes sense to me. However, all the nonsensical things you say =
shouldn=E2=80=99t be allowed are already perfectly allowed today, you ju=
st have to type a bunch of boilerplate reflection code. There is no new =
behavior here, just new syntax.=20

=E2=80=94 Rob
--9722f6cc65404543a9bc6ca629deee85
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Sun, Aug 25, 2024, at 17:31, Rowan Tommins [IMSoP] wro=
te:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div class=3D=
"qt-moz-cite-prefix">On 25/08/2024 14:35, Larry Garfield=0A      wrote:<=
br></div><blockquote type=3D"cite" cite=3D"mid:0cfd3a28-3cb0-4478-85fb-c=
f086d8e5c66@app.fastmail.com"><pre>My other concern is the list of suppo=
rted expression types.  I=20=0Aunderstand how the implementation would n=
aturally make all of those=20=0Asyntactically valid, but it seems many o=
f them, if not most, are=20=0Asemantically nonsensical.<br></pre></block=
quote><p><br></p><p>I tend to agree with Larry and John that the list of=
 operators=0A      should be restricted - we can always allow more in fu=
ture, but=0A      restricting later is much harder.<br></p><p>A few rule=
s that seem logical to me:<br></p><p>1) The expression should be reasona=
bly guaranteed to produce the=0A      same type as the actual default.<b=
r></p><p></p><div>- No casts<br></div><div> - No comparison operators, b=
ecause they produce booleans from=0A      non-boolean input<br></div><di=
v> - No "&lt;=3D&gt;". Technically, it has an integer result, but it's=0A=
      rare to use it as one, rather than a kind of three-value boolean<b=
r></div><div> - No "instanceof"<br></div><div> - No "empty"<br></div><p>=
</p><p>2) The expression should not have side effects (outside of exotic=
=0A      operator overloads).<br></p><p></p><div>- No "include", "requir=
e", etc<br></div><div> - No "throw"<br></div><div> - No "print"<br></div=
><div> - Borderline, but I would also say no "clone"<br></div><p></p><p>=
3) The expression should be passing additional information into=0A      =
the function, not pulling information out of it. The syntax=0A      shou=
ldn't be a way to write obfuscated reflection, or invert data=0A      fl=
ow from callee to caller.<br></p><p></p><div>- No assignments.<br></div>=
<div> - No ternaries with "default" on the left-hand side - "$foo ? $bar=
=0A      : default" is acting on local knowledge, but "default ? $foo :=0A=
      $bar" is acting on information the caller shouldn't know<br></div>=
<div> - Same for "?:" and "??"<br></div><div> - No "match" with "default=
" as the condition or branch, for the=0A      same reason. "match($foo) =
{ $bar =3D&gt; default }" is fine,=0A      match(default) { ... }" or "m=
atch($foo) { default =3D&gt; ... }" are=0A      not.<br></div><p></p><p>=
Note that these can be seen as aspects of the same rule: the aim=0A     =
 of the expression should be to transform the default value into=0A     =
 another value of the same type, not to pull it out and perform=0A      =
arbitrary operations based on it.<br></p><p><br></p><p>I believe that le=
aves us with:<br></p><p></p><div>- Arithmetic operators: binary + - * / =
% **, unary + -<br></div><div> - Bitwise operators: &amp; | ^ &lt;&lt; &=
gt;&gt;&nbsp; ~<br></div><div> - Boolean operators: &amp;&amp; || and or=
 xor !<br></div><div> - Conditions with default on the RHS: $foo ? $bar =
: default, $foo=0A      ?: default, $foo ?? default, match($foo) { $bar =
=3D&gt; default }<br></div><div> - Parentheses: (((default)))<br></div><=
p></p><p><br></p><p>Even then, I look at that list and see more problems=
 than use=0A      cases. As the RFC points out, library authors already =
worry about=0A      the maintenance burden of named argument support, wi=
ll they now=0A      also need to question whether someone is relying on =
"default + 1"=0A      having some specific effect?<br></p><p>Maybe we sh=
ould instead require justification for each addition:<br></p><p></p><div=
>- Bitwise | is nicely demonstrated in the RFC<br></div><div> - Bitwise =
&amp; could probably be justified on similar grounds<br></div><div> - "$=
foo ? $bar : default" is discussed in the RFC<br></div><div> - The other=
 "conditions with default on the RHS" in my shortlist=0A      above fit =
the same basic use case<br></div><p></p><p>Beyond that, I'm struggling t=
o think of meaningful uses:=0A      "whatever the function sets as its d=
efault, do the opposite";=0A      "whatever number the function sets as =
default, raise it to the=0A      power of 3"; etc. Again, they can easil=
y be added in later=0A      versions, if a use case is pointed out.<br><=
/p><p><br></p><p>Regards,<br></p><pre class=3D"qt-moz-signature" cols=3D=
"72">--=20=0ARowan Tommins=0A[IMSoP]<br></pre></blockquote><div><br></di=
v><div>Hi Rowan, you went through a lot of trouble to write this out, an=
d the reasoning makes sense to me. However, all the nonsensical things y=
ou say shouldn=E2=80=99t be allowed are already perfectly allowed today,=
 you just have to type a bunch of boilerplate reflection code. There is =
no new behavior here, just new syntax.&nbsp;<br></div><div><br></div><di=
v id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--9722f6cc65404543a9bc6ca629deee85--