Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104488
MIME-Version: 1.0
References: <CABHuAWy-iTD-weW_pVgg3SZwjLnVe7vdJ_22nR8-xw6tmJRVkQ@mail.gmail.com>
 <CAJW__o0x2C9OA6MnreK1tawhC7BLXET0+Kdk8yGxFq-rQRoQbg@mail.gmail.com>
In-Reply-To: <CAJW__o0x2C9OA6MnreK1tawhC7BLXET0+Kdk8yGxFq-rQRoQbg@mail.gmail.com>
Date: Thu, 21 Feb 2019 16:21:48 +0200
Message-ID: <CA++kX6_NBsqxGm175GC20Vd3Asue2sb9RAgkhwNwoG_WujW03A@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Chris Riley <t.carnage@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV][RFC] Cast in foreach
From: riikka.kalliomaki@riimu.net (=?UTF-8?Q?Riikka_Kalliom=C3=A4ki?=)

On Thu, Feb 21, 2019 at 3:36 PM Kalle Sommer Nielsen <kalle@php.net> wrote:
>
> Den tor. 21. feb. 2019 kl. 14.16 skrev Chris Riley <t.carnage@gmail.com>:
> >
> > Hi internals,
> >
> > I'd like to propose opening an rfc to make the following syntax legal:
> >
> > foreach($array as (int) $i) {}
>
> How would this interact with the foreach-list syntax?

Hi, internals,

I would much rather like to see support for something along the lines of,

foreach ($foo as ClassName $bar) {
    $bar->doStuff();
}

This could be equivalent of (e.g. for casting, type checking and strict typ=
es):

foreach ($foo as $bar) {
    foo($bar);
}

function foo(ClassName $bar) {
    $bar->doStuff();
}

I feel there is currently significant pain when using iterable
pseudotype and generators. It's not possible to indicate in a type
safe manner the yield value of a generator nor what a iterable is
supposed to be returning.

foreach is the structure used (in general) to traverse these and I
very often find myself using something like /** @var ClassName $bar */
preceeding the foreach loop just to have some kind of type
safety/autocomplete via static analysis.

Though, I suppose at least some kind of iterable_apply($iterable,
$function) could also solve this. While it would be easy to create in
userland, I don't like implementing common small functions to a number
of separate libraries. Using the iterable type in PHP is quite painful
at the moment, since most internal functions take either a Traversable
or an array, but rarely both.

Turning an iterable to an indexed array is kinda painful if you want
to leverage the internal type decleration functionality:

function foo (iterable $ints) {
    $actualInts =3D [];

    foreach ($ints as $int) {
        $actualStrings =3D (function (int $int): int {
            return $int;
        })($int);
    }
}

or

function bar (iterable $ints) {
    $actualInts =3D (function (int ... $ints): array {
        return $ints;
    })(... array_values(is_array($ints) ? $ints : iterator_to_array($ints))=
);
}

See, for example: https://3v4l.org/ebRjE

In my mind, the support for foreach-list syntax seems less relevant,
as if you're passing around arrays with specific keys, then you're
probably dealing with more known quantities. At least to me, this is
particularly painful issue when writing library code.

While typed arrays would also solve some of these issues, you'd still
probably have a lot of third party code that would, for example, have
untyped return values and you would also still need a way to type
generator yield values as well.

--=20
Riikka Kalliom=C3=A4ki
https://github.com/Riimu