Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119487
MIME-Version: 1.0
References: <18627e9c82d.1185ba82a2669697.6762525826203739336@wendelladriel.com>
 <CABAhh3EV4TAHjqx=g75qy0BrCsRj+XEu-yoZuzBAcqh-8+h7hg@mail.gmail.com>
 <8c3fb742-4367-0e4a-b96e-142657ac902c@gmail.com> <CAJpLVh3eG4d4rarpBhy5JMJeD_9ZDZiFLT7dQMRruLsCMTGsTQ@mail.gmail.com>
 <5edaa45e-08ff-9529-3a1b-42f655a68497@gmail.com> <CAJpLVh3-PNkJg0gJJGR9VG9S-XN-G0g_Q6VunhtbdDi-jzZoZA@mail.gmail.com>
 <PH8PR10MB63376623B7E735DB70B594B1BFDB9@PH8PR10MB6337.namprd10.prod.outlook.com>
 <CALKiJKo3tuMoOfihDYSr10NQ8MGB0-zDNWHHpa05f6W-vH3HWA@mail.gmail.com>
In-Reply-To: <CALKiJKo3tuMoOfihDYSr10NQ8MGB0-zDNWHHpa05f6W-vH3HWA@mail.gmail.com>
Date: Wed, 8 Feb 2023 14:59:39 +0000
Message-ID: <CA+1VZ8v7jXWm65XMpiyQFGL4M0HhMM4Lt8EymK__so8dhCYhwQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001f307a05f43184bd"
Subject: Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
From: wendelladriel.ti@gmail.com (Wendell Adriel)

--0000000000001f307a05f43184bd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey everyone, it's me, Wendell (that proposed this RFC in the first place).
I'm just using another e-mail because my other email me@wendelladriel.com
is having some issues with the PHP email lists.

First of all, thanks for all the feedback so far on this proposal.
I'm seeing that the implementation would be far more complex than I thought
it would be.
I have two questions about this:

1. Should I move forward on creating the RFC for further discussion? If so,
I know that I need karma for that, I already created my Wiki account with
the email wendelladriel.ti@gmail.com and username wendell_adriel. In the
how-to guide says that I need to ask in this list for the needed Karma, so
if you think that I should move on with this RFC can someone give me the
needed karma for that?

2. It would be great to have someone else aboard with more experience in
the PHP source code and the RFC process since I'm a beginner and this seems
to be way more complex than I first thought. Is there anyone that wants to
work with me on the RFC proposal and the implementation if this should
proceed?

Thanks in advance.
Have an amazing day everyone.

*---*
*Best Regards,*
*Wendell Adriel.*
*Software Engineer **| Investor | Amateur Photographer | Musician | INFP*
*https://wendelladriel.com <https://wendelladriel.com>*


Em qua., 8 de fev. de 2023 =C3=A0s 14:40, Rowan Tommins <rowan.collins@gmai=
l.com>
escreveu:

> On Wed, 8 Feb 2023 at 00:13, Sergii Shymko <sergey@shymko.net> wrote:
>
> > I think, typed variables would be a necessary prerequisite for typed
> > arrays and eventually generics.
> > If my understanding is correct, the primary concern there is performanc=
e
> > overhead of iterating items for type checking.
> > With typed variables, type checking is done at assignment and passing
> > typed array around becomes lightweight.
> > It would be enough to type check against a known array item type withou=
t
> > iterating over items.
> >
> > For example:
> > function do_something(array<string> $strings) {
> >     ...
> > }
> > array<string> $names =3D ['John', 'Jane', 'Jake'];  // items are type
> > checked similar to variadic argument unpacking
> > sort($names);
> > do_something($names);  // lightweight type check as for scalar types
>
>
>
> This is probably more complicated to implement than you're imagining.
>
> Firstly, there is a key distinction between *variables* and *values*: whe=
n
> you say do_something($names), the receiving code in do_something doesn't
> know that the argument it was given is the variable $names, with type
> array<string>; it just receives the value ['John', 'Jane', 'Jake'].
>
> That leads to another distinction: the variable has a single type
> *constraint* ("must always point to a value matching this type"), but the
> value has multiple pieces of type *information* ("has been checked as
> meeting these different constraints"). Both can also be deduced using the
> relationships between types. For example:
>
> function do_something(array<string> $strings) {
>     ...
> }
> function filter_non_strings(array<mixed> $items): array<string> {
>     ...
> }
> array<string|int> $mixed_list =3D ['John', 42, 'Jane'];
> $mixed_list =3D filter_non_strings($mixed_list);
> // when calling filter_non_strings, we know that the value matches
> array<string|int>, so can deduce that it matches array<mixed> as well
> // when assigning the result back to $mixed_list, we know (from the retur=
n
> type check) that it matches array<string>, so can deduce that it matches
> array<string|int> as well
>
> do_something($mixed_list);
> // since the value hasn't changed since it was returned, it still matches
> array<string>, even though the variable doesn't have that constraint
>
> sort($mixed_list);
> // for this call to succeed, we need to know that the variable is an arra=
y;
> we can deduce that from knowing it matches array<string> or knowing that =
it
> matches array<string|int>
> // as a minimum, we need to assert that after modifying it by reference, =
it
> still matches array<string|int>, as required by $mixed_list
> // but do we also still know that it matches array<string>?
>
> It's all probably doable, but I think it's the other way around from your
> initial statement: working out how to cache type checks would be a
> pre-requisite for implementing local variable types.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

--0000000000001f307a05f43184bd--