Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125462
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 07 Sep 2024 01:40:21 +0200
To: internals@lists.php.net
Message-ID: <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
In-Reply-To: <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: multipart/alternative;
 boundary=d3d3816f44b545f3b0a044d32ad3eee5
From: rob@bottled.codes ("Rob Landers")

--d3d3816f44b545f3b0a044d32ad3eee5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Sep 7, 2024, at 01:34, Larry Garfield wrote:
> On Fri, Sep 6, 2024, at 6:27 PM, Rob Landers wrote:
>=20
> >> I suspect there's also other edge case bits to worry about, particu=
larly if trying to combine a complex alias with a complex type, which co=
uld lead to violating the DNF rule.  For example:
> >
> > Oh, DNF is the bane of my existence with this RFC=E2=80=94I don't wa=
nt to mess=20
> > this up. I'll see you at the end of the example, though.
> >
> >>=20
> >> typealias Foo: (Bar&Baz)|Beep;
> >>=20
> >> use (Bar&Baz)|Beep as Foo;
> >>=20
> >> function narf(Foo&Stringable $s) {}
> >>=20
> >> With the compile time approach, that would expand to `(Bar&Baz)|Bee=
p&Stringable`, which is not a valid type def.
> >
> > I can see how you arrived at this, but I think you may have missed a=20
> > step, since the entirety of Foo will be &'d with Stringable.
> >
> > Foo =3D (Bar & Baz) | Beep
> >
> > want: (Foo) & Stringable
> >
> > expand Foo: ((Bar & Baz) | Beep) & Stringable
> >
> > Which can be reduced to the following in proper DNF (at least, it=20
> > compiles=E2=80=94https://3v4l.org/0bMlP):
> >
> > (Beep & Stringable) | (Bar & Baz & Stringable)
> >
> > It's probably a good idea to update the RFC explaining how expansion=
 works.
>=20
> Woof.  We're not "fixingup" anyone's DNF elsewhere.  I cannot speak fo=
r everyone, but I'd be perfectly fine not doing any magic fixing for now=
, and then debating separately if we should do it more generally.  Just =
doing it for aliases doesn't seem like the best plan.
>=20
> --Larry Garfield
>=20

Oh, we're definitely not "fixingup" the expression to DNF... more like s=
pending some time in the RFC showing how the expansion is the same execu=
tion as with a DNF expression to prove that it is a valid type expressio=
n.

=E2=80=94 Rob
--d3d3816f44b545f3b0a044d32ad3eee5
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 Sat, Sep 7, 2024, at 01:34, Larry Garfield wrote:<br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, Sep 6, =
2024, at 6:27 PM, Rob Landers wrote:<br></div><div><br></div><div>&gt;&g=
t; I suspect there's also other edge case bits to worry about, particula=
rly if trying to combine a complex alias with a complex type, which coul=
d lead to violating the DNF rule.&nbsp; For example:<br></div><div>&gt;<=
br></div><div>&gt; Oh, DNF is the bane of my existence with this RFC=E2=80=
=94I don't want to mess&nbsp;<br></div><div>&gt; this up. I'll see you a=
t the end of the example, though.<br></div><div>&gt;<br></div><div>&gt;&=
gt;&nbsp;<br></div><div>&gt;&gt; typealias Foo: (Bar&amp;Baz)|Beep;<br><=
/div><div>&gt;&gt;&nbsp;<br></div><div>&gt;&gt; use (Bar&amp;Baz)|Beep a=
s Foo;<br></div><div>&gt;&gt;&nbsp;<br></div><div>&gt;&gt; function narf=
(Foo&amp;Stringable $s) {}<br></div><div>&gt;&gt;&nbsp;<br></div><div>&g=
t;&gt; With the compile time approach, that would expand to `(Bar&amp;Ba=
z)|Beep&amp;Stringable`, which is not a valid type def.<br></div><div>&g=
t;<br></div><div>&gt; I can see how you arrived at this, but I think you=
 may have missed a&nbsp;<br></div><div>&gt; step, since the entirety of =
Foo will be &amp;'d with Stringable.<br></div><div>&gt;<br></div><div>&g=
t; Foo =3D (Bar &amp; Baz) | Beep<br></div><div>&gt;<br></div><div>&gt; =
want: (Foo) &amp; Stringable<br></div><div>&gt;<br></div><div>&gt; expan=
d Foo: ((Bar &amp; Baz) | Beep) &amp; Stringable<br></div><div>&gt;<br><=
/div><div>&gt; Which can be reduced to the following in proper DNF (at l=
east, it&nbsp;<br></div><div>&gt; compiles=E2=80=94<a href=3D"https://3v=
4l.org/0bMlP">https://3v4l.org/0bMlP</a>):<br></div><div>&gt;<br></div><=
div>&gt; (Beep &amp; Stringable) | (Bar &amp; Baz &amp; Stringable)<br><=
/div><div>&gt;<br></div><div>&gt; It's probably a good idea to update th=
e RFC explaining how expansion works.<br></div><div><br></div><div>Woof.=
&nbsp; We're not "fixingup" anyone's DNF elsewhere.&nbsp; I cannot speak=
 for everyone, but I'd be perfectly fine not doing any magic fixing for =
now, and then debating separately if we should do it more generally.&nbs=
p; Just doing it for aliases doesn't seem like the best plan.<br></div><=
div><br></div><div>--Larry Garfield<br></div><div><br></div></blockquote=
><div><br></div><div>Oh, we're definitely not "fixingup" the expression =
to DNF... more like spending some time in the RFC showing how the expans=
ion is the same execution as with a DNF expression to prove that it is a=
 valid type expression.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--d3d3816f44b545f3b0a044d32ad3eee5--