Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101683
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDChcXX98o1_AbKTTBjHMTdWBbh286CO1uK_mucBBZGZyTA@mail.gmail.com>
References: <CAEUnE0cRR6jtU2GoeiP4SDLJejF4+6zY=fT1FiTKPe6aKwoFqg@mail.gmail.com>
 <alpine.DEB.2.21.1801251441310.24989@singlemalt.home.derickrethans.nl>
 <9b12b0e2-185e-86fb-0e0b-c4f24bfbd661@gmail.com> <CAEUnE0fBE2eGbfimWw+AhPG+ZZ8WRNDLB+i1wE14NF_HARbQHQ@mail.gmail.com>
 <CANUQDChnG6fzFTr-RWixscg7pRy+dgqhwvUetRzjDxifmSiXHw@mail.gmail.com>
 <CAEUnE0dquLRkAf=ezF7Ufw9b2g6Hhgrs5FXN0_+N7z6drOEkJA@mail.gmail.com> <CANUQDChcXX98o1_AbKTTBjHMTdWBbh286CO1uK_mucBBZGZyTA@mail.gmail.com>
Date: Thu, 25 Jan 2018 19:06:34 -0600
Message-ID: <CAEUnE0eG8=iefTj8wQ+iBKrDr6smMhoogOZN2Ew=26gr3X7NhA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c087652f31b680563a38173"
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection
From: tendoaki@gmail.com (Michael Morris)

--94eb2c087652f31b680563a38173
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <me@kelunik.com> wrote:

>
>>
>> $a instanceof array<string>
>>
>
> That might work, but array<string> should only return true if it's an
> array, not for anything that implements ArrayAccess.
>
>

Related:

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <levim@php.net> wrote:

>
>
> I see no value to this operator being applied to non-array
> traversables.


If an array access object can't masquerade as an array it loses some of its
value, but Niklas is right - it is important to distinguish such objects
from native arrays.  One solution would be to promote "iterable" to keyword
status.  The flexibility to take any iterable will be needed I think.

$a instanceof iterable<string>

Would return true for anything iterable (which we can already test with
is_iterable() ) where all values where strings.

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <levim@php.net> wrote:
>
> Our iterators cannot always be reliably rewound, such as
> when using generators. Checking that the generator returns only
> strings would consume all the input and would therefore be useless.


True - I hadn't thought of those. But as of PHP 7 generators can type
declare their return value.  So, given `$a instanceof iterable<string>`, if
$a is a reference to a generator, then the engine could check the return
type declaration and only give true on a match without attempting to use
the generator.

We can follow this pattern farther - The return of an
ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
instanceof rather than actually pulling data from these methods.

We are having the return rely on the promise of the code, but in each case
TypeError would be raised anyway if it breaks it's promise to instanceof so
errors aren't being avoided.



> Returns true if $a is an array (or implements array access) and that all
>> it's members are strings.
>>
>> $b instanceof SomeClass<string>
>>
>> Returns true if SomeClass can be iterated and contains only strings.
>>
>
> This would block generics with that syntax then.
>

I don't understand this comment.


On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield <larry@garfieldtech.com>
 wrote:

>
>
> Is this to ensure that everything coming OUT of a collection is a given
> type,
> or that everything put IN a collection is a given type?
>

Ensure (or try to ensure, since reporting the promises of another method's
return type isn't certain) that things coming OUT are a given type.  Leave
the headache of guarding inputs for another day and RFC.


>
> Asserting that "at this point in time, everything in this collection is a
> given type" is honestly fairly useless unless it's enforced to stay that
> way.


No more useless than type declarations are if a programmer does this...

function foo (string $a) {
  $a = (int) $a;
}

Every feature of the language can be rendered useless by the right amount
of stupidity. No feature recommendation should be beholden to the "what if
a moron does X?" argument.

--94eb2c087652f31b680563a38173--