Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125223
Date: Sun, 25 Aug 2024 12:23:20 -0400
To: =?utf-8?Q?Rowan_Tommins_=5BIMSoP=5D?= <imsop.php@rwec.co.uk>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <9B1A7EFF-1AB3-4DCD-9A14-AF9FD5EE504C@getmailspring.com>
In-Reply-To: <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
References: <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cb5a78_66334873_11f93"
From: john@coggeshall.org (John Coggeshall)

--66cb5a78_66334873_11f93
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
>
>
> 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
>
>

IMO the operations that make sense in this context are:
- Some Bitwise operators: & | ^
- Conditions with default on the RHS: $foo ? $bar : default, $foo ?: default, $foo ?? default, match($foo) { $bar => default }
- Parentheses: (((default)))

> 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.
I 100% agree.
> G((default)->F()); // lol
> Special-casing the T_DEFAULT grammar would not only bloat the grammar rules but also increase the chance that new expression grammars introduced in future, which could conveniently interoperate with `default`, would be unintentionally excluded by omission.

I won't vote for this RFC if the above code is valid, FWIW. Unlike include , default is a special-case with a very specific purpose -- one that is reaching into someone else's API in a way the developer of that library doesn't explicitly permit. It should not become a fast easy way to inject a new potentially complex dependency which is what allowing a full expression support would allow.
The fact that Reflection allows me to pull out a private member doesn't mean accessing private members of objects should be given its own language syntax.
Frankly, not only should the op list be limited but ideally it should also only be valid based on the type of the upstream API call (e.g. bitwise operators should only be valid if the upstream API call has a type int ).

--66cb5a78_66334873_11f93
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 25 2024, at=
 11:31 am, Rowan Tommins =5BIMSoP=5D &lt;imsop.php=40rwec.co.uk&gt; wrote=
:</div><blockquote><br></blockquote><blockquote><br><div>Even then, I loo=
k at that list and see more problems than use cases. As the R=46C 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 =22default + 1=22 having some specific effect=3F</div><br><div=
>Maybe we should instead require justification for each addition:</div><b=
r><div><div>- Bitwise =7C is nicely demonstrated in the R=46C</div><div>-=
 Bitwise &amp; could probably be justified on similar grounds</div><div>-=
 =22=24foo =3F =24bar : default=22 is discussed in the R=46C</div><div>- =
The other =22conditions with default on the RHS=22 in my shortlist above =
fit the same basic use case</div></div><br></blockquote><br><div>IMO the =
operations that make sense in this context are:</div><br><div>- <u>Some <=
/u>Bitwise operators: &amp; =7C =5E </div><div>- Conditions with default =
on the RHS: =24foo =3F =24bar : default, =24foo =3F: default, =24foo =3F=3F=
 default, match(=24foo) =7B =24bar =3D&gt; default =7D</div><div>- Parent=
heses: (((default)))</div><br><blockquote><div><div>Beyond that, I'm stru=
ggling to think of meaningful uses: =22whatever the function sets as its =
default, do the opposite=22; =22whatever number the function sets as defa=
ult, raise it to the power of 3=22; etc. Again, they can easily be added =
in later versions, if a use case is pointed out.</div></div></blockquote>=
<br><div>I 100% agree.</div><br><blockquote>G((default)-&gt;=46()); // lo=
l</blockquote><blockquote><font style=3D=22font-size:14.5px=22><font styl=
e=3D=22font-family:Nylas-Pro, Helvetica, &quot;Lucidia Grande&quot;, sans=
-serif=22></font></font></blockquote><blockquote><font style=3D=22font-si=
ze:14.5px=22><font style=3D=22font-family:Nylas-Pro, Helvetica, &quot;Luc=
idia Grande&quot;, sans-serif=22>Special-casing the T=5FDE=46AULT grammar=
 would not only bloat the grammar rules but also increase the chance that=
 new expression grammars introduced in future, which could conveniently i=
nteroperate with =60default=60, would be unintentionally excluded by omis=
sion.</font></font></blockquote><br><div>I won't vote for this R=46C if t=
he above code is valid, =46WIW. Unlike <code>include</code>&nbsp;, <code>=
default</code>&nbsp; is a special-case with a very specific purpose -- on=
e that is reaching into someone else's API in a way the developer of that=
 library doesn't explicitly permit. It should not become a fast easy way =
to inject a new potentially complex dependency which is what allowing a f=
ull expression support would allow. </div><br><div>The fact that Reflecti=
on allows me to pull out a private member doesn't mean accessing private =
members of objects should be given its own language syntax.</div><br><div=
>=46rankly, not only should the op list be limited but ideally it should =
also only be valid based on the type of the upstream API call (e.g. bitwi=
se operators should only be valid if the upstream API call has a type <co=
de>int</code>&nbsp;).</div><br>
--66cb5a78_66334873_11f93--