Re: [RFC] Pure intersection types
Personally, I am against the syntax used in the PR for composite
types( even tho i don't have voting powers ).
I would prefer a syntax similar to Hack, where you have to use parentheses to make things more
explicit.
considering the following Hack code:
interface A {}
interface B {}
interface C {}
interface D {}
interface E {}
interface F {}
function bar(
((A & F) | (((A & B) | (C & D)) & E)) $_foo
): void {}
In PHP, i would assuming i can just remove the parentheses and it would work as expected:
<?php
interface A {}
interface B {}
interface C {}
interface D {}
interface E {}
interface F {}
function bar(
A&F|A&B|C&D&E $_foo
): void {}
However, this now allows A&B, which previous was not allowed, so the correct
translation is:
<?php
interface A {}
interface B {}
interface C {}
interface D {}
interface E {}
interface F {}
function bar(
A&F|A&B&E|C&D&E $_foo
): void {}
which is way much more confusing, can lead to type errors, and be more repetitive ( e.g: A
& ( B | C ) vs A & B | A & C - A mentioned twice )
ref: https://twitter.com/azjezz/status/1373439678045683721
/ https://twitter.com/azjezz/status/1373647148026322946
Regards,
Saif.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, April 3, 2021 1:22 PM, G. P. B. <george.banyard@gmail.com> wrote:
> On Tue, 23 Mar 2021 at 19:45, Matthew Brown matthewmatthew@gmail.com
> wrote:
>
> > On Tue, 23 Mar 2021 at 05:32, G. P. B. george.banyard@gmail.com wrote:
> >
> > > I'm calling this proposal pure intersection types as there would be no
> > > possibility of mixing intersection and union types, I'm leaving this as a
> > > future scope.
> >
> > Does this miss an opportunity, though? It's useful to be able to write
> > A&B|null.
>
> Obviously this is less powerful than support for composite types where one
> can use both intersections and unions.
>
> I've tried implementing composite types without grouping here:
> https://github.com/Girgias/php-src/pull/8
> But I'm hitting various issues and I'm far from confident that I'll be able
> to resolve them and add the variance check code before June so that this
> can reasonably get voted in for PHP 8.1.
>
> The end goal is support for composite types but I prefer to land a
> reasonably self contained feature in 8.1 then nothing at all.
> Internals might disagree with this and refuse the feature unless "complete"
> but if that's the case there is still time to "finish" it for another RFC..
>
> If someone else wants to work on adding support for composite types they
> are free to work based on my PR, or collaborate with me.
>
> I've also tidied up the RFC: https://github.com/Girgias/intersection-types
>
> Unless someone shows up to work on composite types, I'll probably bring
> this to a vote next week (if I don't forget about it).
>
> Best regards,
>
> George P. Banyard
Thread (13 messages)