Michael Morris <tendo...@gmail.com> schrieb am Fr., 26. Jan. 2018, 02:06:
> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <m...@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 <le...@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 <le...@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.
They can only define generator as return type, which is what they return
when you call a generator function.
Even if you could declare the return type of the generator, you'd still
have the same problem with the yielded values.
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.
>
You restrict these type parameters to iterators, but generics are useful in
a lot more places.
> On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield <la...@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.
>
Regards, Niklas
>
