Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.181 as permitted sender)
MIME-Version: 1.0
Sender: jesseschalken@gmail.com
In-Reply-To: <CAFKaYMo5rtXeV+uE85yuQ_xOpREiKF-zVdQN6T-vDET8WhFvzg@mail.gmail.com>
References: <CADqTB_gUbfu91QRm1U0KyDjai8DKw7yCE6QxgUecy60oq3Zi8Q@mail.gmail.com>
	<CAKiSzdCO83XM0zqAeFnjQEMJvbd0yBmYAFnj0H6AtDumofVbkw@mail.gmail.com>
	<CAKiSzdCCEF=7OWtvZETG3bRoByCCLqEAEjuLW_H6m7MmDtJ8_g@mail.gmail.com>
	<CAFKaYMoQUUFLqgDjOHj3W0+a63u3s=vqnU5gWMCj0zvmvXFF5Q@mail.gmail.com>
	<3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net>
	<CAESVnVqCZnrbHa+5_tSYG70VyvGfpZoDM98bEst3pg36HahYEg@mail.gmail.com>
	<57173859.4080501@rochette.cc>
	<CAFKaYMq_KFrygXwcuTd85y11X0_YMFop2tum+8jjXnkGKON6QA@mail.gmail.com>
	<CAFp73Xu2dM+E9Ri8dN-yt9Ha6-1UmOtD0RYq+HZXbjvzcWqJwg@mail.gmail.com>
	<CAFKaYMpWN+9uBqJ_p6-p14ZqYm0cm+q3LHkY3o9q7EvFCBS9Bg@mail.gmail.com>
	<CAFKaYMo5rtXeV+uE85yuQ_xOpREiKF-zVdQN6T-vDET8WhFvzg@mail.gmail.com>
Date: Thu, 21 Apr 2016 07:02:04 +1000
Message-ID: <CAF1yvAQh2O6gdczOa6X5TTi55Nd8AMrjjmR9LX+szmy8aaHdxA@mail.gmail.com>
To: Dominic Grostate <codekestrel@googlemail.com>
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>, Mathieu Rochette <mathieu@texthtml.net>, 
	Josh Di Fabio <joshdifabio@gmail.com>, "Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Rasmus Schultz <rasmus@mindplay.dk>, 
	Mathieu Rochette <mathieu@rochette.cc>
Content-Type: multipart/alternative; boundary=047d7bdc15baeeadca0530f0e7b8
Subject: Re: [PHP-DEV] [RFC:generics]
From: me@jesseschalken.com (Jesse Schalken)

--047d7bdc15baeeadca0530f0e7b8
Content-Type: text/plain; charset=UTF-8

"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 <
codekestrel@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.
>

--047d7bdc15baeeadca0530f0e7b8--