Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125068
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 20 Aug 2024 14:42:19 +0200
To: "Arnaud Le Blanc" <arnaud.lb@gmail.com>
Cc: internals@lists.php.net
Message-ID: <dabbb556-18b9-4738-962a-b6a985efccd3@app.fastmail.com>
In-Reply-To: 
 <CAP1Jc135dqPNzqja6LSVg3R-Z2d1MHv-u7L_JUGm7gnbdE+VPQ@mail.gmail.com>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <d9067561-8a1b-45f0-9d38-51fe7fe9371b@app.fastmail.com>
 <CAP1Jc135dqPNzqja6LSVg3R-Z2d1MHv-u7L_JUGm7gnbdE+VPQ@mail.gmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: multipart/alternative;
 boundary=f9a4dcb2c5094dc1a7d6cc518f873b81
From: rob@bottled.codes ("Rob Landers")

--f9a4dcb2c5094dc1a7d6cc518f873b81
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2024, at 14:08, Arnaud Le Blanc wrote:
> Hi Rob,
>=20
> On Mon, Aug 19, 2024 at 7:51=E2=80=AFPM Rob Landers <rob@bottled.codes=
> wrote:
>=20
> > > Invariance would make arrays very difficult to adopt, as a library=
 can not start type hinting generic arrays without breaking user code, a=
nd users can not pass generic arrays to libraries until they start using=
 generic arrays type declarations.
> >
> > This seems like a strawman argument, to a degree. In other words, it=
 seems like you could combine static arrays and fluid arrays to accompli=
sh what you are seeking to do. In other words, use static arrays but all=
ow casting to treat it as "fluid."
> >
> > In other words, simply cast to get your example to compile:
> >
> > function f(array<int> $a) {}
> > function g(array $a) {}
> >
> > $a =3D (array<int>) [1]; // array unless cast
> >
> > f($a); // ok
> > g((array)$a); // ok
> >
> > And the other way:
> >
> > function f(array<int> $a) {}
> > function g(array $a) {}
> >
> > $a =3D [1];
> >
> > f((array<int>)$a); // ok, type check done during cast
> > g($a); // ok
>=20
> There is potential for breaking changes in both of your examples:
>=20
> If f() is a library function that used to be declared as `f(array
> $a)`, then changing its declaration to `f(array<int> $a)` is a
> breaking change in the Static Arrays flavour, as it would break
> library users until they change their code to add casts.

I don't think we should be scared of breaking changes; php 9.0 is coming=
 =F0=9F=94=9C anyway. You could also consider it as "an array might be a=
rray<T>, but an array<T> is always an array"

>=20
> Similarly, the following code would break (when calling g()) if h()
> was changed to return an array<int>:
>=20
> function h(): array {}
> function g(array $a);
>=20
> $a =3D h();
> g($a);
>=20
> Casting would allow users to pass generic arrays to libraries that
> don't support generics yet, but that's expensive as it requires a
> copy.

Why does it require a copy? It should only require a copy if the content=
s are changed (CoW) and at that point, you can know what rules to apply =
based on the coerced/casted type. I'm doing a similar thing for the Lite=
ral Strings RFC, where it is a type that is also indistinguishable from =
a string until something happens to it and it is no longer a literal str=
ing.

So passing a array<int> to a function that only accepts an array shouldn=
't matter. Once inside that function, all type-checking can be disabled =
for that array. One approach to that could be to just smack a "type-chec=
k strategy" function pointer on zvals, potentially, as that would give t=
he most flexibility for casting, aliases, generics, etc. Don't get me st=
arted on the current type checking; it is a mess and inconsistent depend=
ing on what is doing the checking (constructor promoted props, propertie=
s, method args, function args). Then you can just copy the zval, change =
a function pointer, but point it to the same array (which will CoW) and =
change the strategy during casting.

In other words, you could cheaply cast an array<int> to array<string> by=
 (essentially) changing a couple of function pointers, but array<string>=
 to array<int> would be expensive. So I imagine there would strategies f=
or changing strategies... probably. I don't know, I literally just thoug=
ht of this off the top of my head, so it probably needs more work.

>=20
> Best Regards,
> Arnaud
>=20


=E2=80=94 Rob
--f9a4dcb2c5094dc1a7d6cc518f873b81
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 Tue, Aug 20, 2024, at 14:08, Arnaud Le Blanc wrote:<br=
></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi Rob,<br></=
div><div><br></div><div>On Mon, Aug 19, 2024 at 7:51=E2=80=AFPM Rob Land=
ers &lt;<a href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; w=
rote:<br></div><div><br></div><div>&gt; &gt; Invariance would make array=
s very difficult to adopt, as a library can not start type hinting gener=
ic arrays without breaking user code, and users can not pass generic arr=
ays to libraries until they start using generic arrays type declarations=
.<br></div><div>&gt;<br></div><div>&gt; This seems like a strawman argum=
ent, to a degree. In other words, it seems like you could combine static=
 arrays and fluid arrays to accomplish what you are seeking to do. In ot=
her words, use static arrays but allow casting to treat it as "fluid."<b=
r></div><div>&gt;<br></div><div>&gt; In other words, simply cast to get =
your example to compile:<br></div><div>&gt;<br></div><div>&gt; function =
f(array&lt;int&gt; $a) {}<br></div><div>&gt; function g(array $a) {}<br>=
</div><div>&gt;<br></div><div>&gt; $a =3D (array&lt;int&gt;) [1]; // arr=
ay unless cast<br></div><div>&gt;<br></div><div>&gt; f($a); // ok<br></d=
iv><div>&gt; g((array)$a); // ok<br></div><div>&gt;<br></div><div>&gt; A=
nd the other way:<br></div><div>&gt;<br></div><div>&gt; function f(array=
&lt;int&gt; $a) {}<br></div><div>&gt; function g(array $a) {}<br></div><=
div>&gt;<br></div><div>&gt; $a =3D [1];<br></div><div>&gt;<br></div><div=
>&gt; f((array&lt;int&gt;)$a); // ok, type check done during cast<br></d=
iv><div>&gt; g($a); // ok<br></div><div><br></div><div>There is potentia=
l for breaking changes in both of your examples:<br></div><div><br></div=
><div>If f() is a library function that used to be declared as `f(array<=
br></div><div>$a)`, then changing its declaration to `f(array&lt;int&gt;=
 $a)` is a<br></div><div>breaking change in the Static Arrays flavour, a=
s it would break<br></div><div>library users until they change their cod=
e to add casts.<br></div></blockquote><div><br></div><div>I don't think =
we should be scared of breaking changes; php 9.0 is coming =F0=9F=94=9C =
anyway. You could also consider it as "an array might be array&lt;T&gt;,=
 but an array&lt;T&gt; is always an array"<br></div><div><br></div><bloc=
kquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>Similarly,=
 the following code would break (when calling g()) if h()<br></div><div>=
was changed to return an array&lt;int&gt;:<br></div><div><br></div><div>=
function h(): array {}<br></div><div>function g(array $a);<br></div><div=
><br></div><div>$a =3D h();<br></div><div>g($a);<br></div><div><br></div=
><div>Casting would allow users to pass generic arrays to libraries that=
<br></div><div>don't support generics yet, but that's expensive as it re=
quires a<br></div><div>copy.<br></div></blockquote><div><br></div><div>W=
hy does it require a copy? It should only require a copy if the contents=
 are changed (CoW) and at that point, you can know what rules to apply b=
ased on the coerced/casted type. I'm doing a similar thing for the Liter=
al Strings RFC, where it is a type that is also indistinguishable from a=
 string until something happens to it and it is no longer a literal stri=
ng.<br></div><div><br></div><div>So passing a array&lt;int&gt; to a func=
tion that only accepts an array shouldn't matter. Once inside that funct=
ion, all type-checking can be disabled for that array. One approach to t=
hat could be to just smack a "type-check strategy" function pointer on z=
vals, potentially, as that would give the most flexibility for casting, =
aliases, generics, etc. Don't get me started on the current type checkin=
g; it is a mess and inconsistent depending on what is doing the checking=
 (constructor promoted props, properties, method args, function args). T=
hen you can just copy the zval, change a function pointer, but point it =
to the same array (which will CoW) and change the strategy during castin=
g.<br></div><div><br></div><div>In other words, you could cheaply cast a=
n array&lt;int&gt; to array&lt;string&gt; by (essentially) changing a co=
uple of function pointers, but array&lt;string&gt; to array&lt;int&gt; w=
ould be expensive. So I imagine there would strategies for changing stra=
tegies... probably. I don't know, I literally just thought of this off t=
he top of my head, so it probably needs more work.<br></div><div><br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>Be=
st Regards,<br></div><div>Arnaud<br></div><div><br></div></blockquote><d=
iv><br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></=
div></body></html>
--f9a4dcb2c5094dc1a7d6cc518f873b81--