"instanceof" implies to me that the right hand side is a class/interface
name, since that's what's expected with the "instanceof" operator, rather
than a type. If I can do "Foo<T instanceof array<Bar>>" I would expect to
be able to do "if ($t instanceof array<Bar>) ...", but I can't.
I think unless the "instanceof" operator is updated to be able to do checks
with arbitrary type expressions, a different keyword should be used for
generic type constraints so as not to imply any misleading correspondence
with the "instanceof" operator.
So I would prefer "as". It's also shorter, and matches Hack.
On Thu, Apr 21, 2016 at 5:17 AM, Dominic Grostate <
codekest...@googlemail.com> wrote:
> Thanks for you're input everyone.
>
> So far, we have read some ideas for handling upper bounds, or multiple
> there of.
> The preferred keywords appear to be either "as" or "instanceof".
>
> class Foo<T as Bar> {}
> class Foo<T instanceof Bar> {}
>
> We would like to know for sure then if everyone is largely against the
> addition of an "is" keyword, in favour of one of the other two.
>
> ----------------
>
> There is also a desire to include unions and intersections.
> Presently though, this feature feels tied in with
> https://wiki.php.net/rfc/union_types meaning if union types are approved,
> then generics would have to support them as well. Likewise if this feature
> becomes approved in generics, it would make sense to support them in
> regular type hints as well.
>
> ----------------
>
> The RFC makes a reference to generic closures, which may look something
> like this:
>
> function my_function(callable<Foo, Bar> $func) {
>
> }
>
> However, an RFC already exists which is very similar to this feature at
> https://wiki.php.net/rfc/callable-types
> As it currently standards these RFCs appear incompatible with each other
> (please correct me if I am wrong).
>
> My question about this is would you prefer the generics RFC exclude this
> part in favour of a separate or later RFC.
> Initially the proposal included generic arrays "array<string>". However to
> ease the implementation it was decided that should be a separate feature.
> So we'd like to find out if everyone else feels the same way about callable
> types.
>
> ----------------
>
> This RFC currently doesn't specify in detail how reflection would work. We
> have attempted a few API designs, but due to generic classes being ...
> generic, it is difficult to find a suitable way to glean information about
> a class in a backwards compatible manner. So we will need some help on
> this one.
>
> -----------------
>
> Aside from these top issues on our own list, however does everyone feel
> about the proposal in general?
> As the RFC is still in draft, we will continue to make changes to it as
> more popular idea pop up, so please continue.
>
> Thanks.
>
> PS: I wasn't properly subscribed to the mailing list, so I missed a few
> important messages that were mailed directly to internals, but hopefully
> I've managed to fix that now.
>
