Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125376
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 01 Sep 2024 18:45:57 +0200
To: internals@lists.php.net
Message-ID: <b7974bd0-4c04-4545-b5a0-fad72b71f45d@app.fastmail.com>
In-Reply-To: <d9dfb1da-4608-4a27-865f-f4a7ea42db26@rwec.co.uk>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <fe37b0bc-af11-4209-94bd-c60db59671ff@scriptfusion.com>
 <d9dfb1da-4608-4a27-865f-f4a7ea42db26@rwec.co.uk>
Subject: Re: [PHP-DEV] Re: [RFC] Default expression
Content-Type: multipart/alternative;
 boundary=6df47ec90fd249429f8b8eccdb57534b
From: rob@bottled.codes ("Rob Landers")

--6df47ec90fd249429f8b8eccdb57534b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 1, 2024, at 14:39, Rowan Tommins [IMSoP] wrote:
> On 29/08/2024 22:52, Bilge wrote:
> > On 24/08/2024 17:49, Bilge wrote:
> >>
> >> New RFC just dropped: https://wiki.php.net/rfc/default_expression. =
I=20
> >> think some of you might enjoy this one. Hit me with any feedback.
> >>
> > Now the dust has settled, I've updated the RFC to version 1.1. The=20
> > premise of the RFC is unchanged, but the proposal has been expanded=20
> > and a discussion section added to summarise the ~100 message thread =
to=20
> > capture the major concerns raised in a condensed format. I hope I've=20
> > done a good job of fairly and accurately representing your concerns,=20
> > but if not please correct me.
>=20
>=20
> As promised, I have written up a full explanation of the type safety=20
> issues here: https://wiki.php.net/rfc/default_expression/type_safety
>=20
> I have tried to write this as a neutral description of the problem and=20
> the possible approaches we could take, to be inserted directly into th=
e=20
> current RFC, rather than as a counter-opinion or a narrative of who sa=
id=20
> what.
>=20
> I have included the 4 options which I believe are the only ones we hav=
e;=20
> it is then a matter of opinion which we think is best. For the record,=20
> my opinion remains that option 3 (limit to conditional expressions) is=20
> preferable, but I have assumed the RFC will continue to advocate for=20
> option 1 (allow any expression and assume problems will be rare).
>=20
> I hope I have explained it clearly enough this time to overcome the=20
> previous misunderstandings of where the issue lies.
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20

Thank you Rowan,

I wasn't following the discussion closely and didn't realize this was th=
e issue. Thank you for taking the time to describe it.

For option 1:=20

Is manually copying the default also not type-safe? Is php a type-safe l=
anguage? I think a lot of the arguments I saw suggested that people don'=
t review libraries and their implementations when upgrading or installin=
g them. This is just a shorthand for manually copy-pasting the default f=
rom other code, and this argument really only makes sense to me if there=
 are no reviews before upgrading/using a library.

For option 3:

That being said, this is obviously playing with fire, and there will be =
people who (ab)use this and get burned; especially if they don't do due-=
diligence before using libraries. Thus a restriction may make a lot of s=
ense; at least keeping it to the most obvious use cases should prevent t=
he worst case scenarios imagined in this thread.

Realistically, I think we should only consider option (1) or (3). Option=
 (3) -- if it can be done -- is the more conservative approach, and we c=
an observe how it is used. We can always relax the feature in the future=
, based on feedback.

=E2=80=94 Rob
--6df47ec90fd249429f8b8eccdb57534b
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>On Sun, Sep 1, =
2024, at 14:39, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 29/08/2024 22:52, Bilge wrote:<br></=
div><div>&gt; On 24/08/2024 17:49, Bilge wrote:<br></div><div>&gt;&gt;<b=
r></div><div>&gt;&gt; New RFC just dropped:&nbsp;<a href=3D"https://wiki=
.php.net/rfc/default_expression">https://wiki.php.net/rfc/default_expres=
sion</a>. I&nbsp;<br></div><div>&gt;&gt; think some of you might enjoy t=
his one. Hit me with any feedback.<br></div><div>&gt;&gt;<br></div><div>=
&gt; Now the dust has settled, I've updated the RFC to version 1.1. The&=
nbsp;<br></div><div>&gt; premise of the RFC is unchanged, but the propos=
al has been expanded&nbsp;<br></div><div>&gt; and a discussion section a=
dded to summarise the ~100 message thread to&nbsp;<br></div><div>&gt; ca=
pture the major concerns raised in a condensed format. I hope I've&nbsp;=
<br></div><div>&gt; done a good job of fairly and accurately representin=
g your concerns,&nbsp;<br></div><div>&gt; but if not please correct me.<=
br></div><div><br></div><div><br></div><div>As promised, I have written =
up a full explanation of the type safety&nbsp;<br></div><div>issues here=
:&nbsp;<a href=3D"https://wiki.php.net/rfc/default_expression/type_safet=
y">https://wiki.php.net/rfc/default_expression/type_safety</a><br></div>=
<div><br></div><div>I have tried to write this as a neutral description =
of the problem and&nbsp;<br></div><div>the possible approaches we could =
take, to be inserted directly into the&nbsp;<br></div><div>current RFC, =
rather than as a counter-opinion or a narrative of who said&nbsp;<br></d=
iv><div>what.<br></div><div><br></div><div>I have included the 4 options=
 which I believe are the only ones we have;&nbsp;<br></div><div>it is th=
en a matter of opinion which we think is best. For the record,&nbsp;<br>=
</div><div>my opinion remains that option 3 (limit to conditional expres=
sions) is&nbsp;<br></div><div>preferable, but I have assumed the RFC wil=
l continue to advocate for&nbsp;<br></div><div>option 1 (allow any expre=
ssion and assume problems will be rare).<br></div><div><br></div><div>I =
hope I have explained it clearly enough this time to overcome the&nbsp;<=
br></div><div>previous misunderstandings of where the issue lies.<br></d=
iv><div><br></div><div>Regards,<br></div><div><br></div><div>--&nbsp;<br=
></div><div>Rowan Tommins<br></div><div>[IMSoP]<br></div><div><br></div>=
</blockquote><div><br></div><div>Thank you Rowan,<br></div><div><br></di=
v><div>I wasn't following the discussion closely and didn't realize this=
 was the issue. Thank you for taking the time to describe it.<br></div><=
div><br></div><div>For option 1: <br></div><div><br></div><div>Is manual=
ly copying the default also not type-safe? Is php a type-safe language? =
I think a lot of the arguments I saw suggested that people don't review =
libraries and their implementations when upgrading or installing them. T=
his is just a shorthand for manually copy-pasting the default from other=
 code, and this argument really only makes sense to me if there are no r=
eviews before upgrading/using a library.<br></div><div><br></div><div>Fo=
r option 3:<br></div><div><br></div><div>That being said, this is obviou=
sly playing with fire, and there will be people who (ab)use this and get=
 burned; especially if they don't do due-diligence before using librarie=
s. Thus a restriction may make a lot of sense; at least keeping it to th=
e most obvious use cases should prevent the worst case scenarios imagine=
d in this thread.<br></div><div><br></div><div>Realistically, I think we=
 should only consider option (1) or (3). Option (3) -- if it can be done=
 -- is the more conservative approach, and we can observe how it is used=
. We can always relax the feature in the future, based on feedback.<br><=
/div><div><br></div><div>=E2=80=94 Rob<br></div></body></html>
--6df47ec90fd249429f8b8eccdb57534b--