intersection types and null for defaults, properties and return types

Agree, an RFC looks like the only way.

This is not worth delaying a release for, nor is it worth postponing the
feature freeze date.

It seems reasonable to fix this after freeze, would prefer to reach
consensus before RC stage.

Cheers
Joe

On Mon, Jul 19, 2021 at 8:16 PM G. P. B. george.banyard@gmail.com
wrote:

On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier <
guilliam.xavier@gmail.com>
wrote:

On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas <
nicolas.grekas@gmail.com

wrote:

https://github.com/php/php-src/pull/7259

Great! Thanks! Interesting how it works out-of-the-box with just this
addition in Zend/zend_language_parser.y:

 type_expr:
  type { $$ = $1; }
  | '?' type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; }
  | union_type { $$ = $1; }
  | intersection_type { $$ = $1; }
+ | '?' intersection_type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; }
 ;

On Mon, Jul 19, 2021 at 5:09 PM Dan Ackroyd Danack@basereality.com
wrote:

nicolas-grekas wrote on the PR:

?X&Y cannot be confused with

It confused me. A compiler might understand it, but as a human I
have
trouble understanding it.

Trowski wrote:

The syntax should be either ?(X&Y) or (X&Y)|null

Non-ambiguous syntax is much better than ambiguous syntax.

Maybe it's just a matter of habit?
For instance I got used to seeing things like !$x = f() (e.g. if (!$x = f()) { throw /*...*/; } /* use $x */) because some CS consider
explicit
parentheses in !($x = f()) redundant (as PHP has a special case that
"overrides" the normal precedence (!$x) = f() which would be an
error).
If you first consider X&Y as a type "unit", then it makes sense to
make
it "nullable" by prefixing it with ?, I think?

But this discussion is moot for 8.1.

This limitation might make intersection types not be considered
usable
by some projects, but the feature freeze is today.

Which can also be reversed: "The feature freeze is today, but this
limitation might make intersection types not be considered usable by
some
projects"? (playing devil's advocate, I don't master the process)

Regards,

--
Guilliam Xavier

Since when is usability for a specific project a consideration an RFC
needs
to have?
If Symfony can't use it in its current state tough luck,
I'm sure plenty of other projects can, especially now that using 'new
Class' is possible as a default object value.

I frankly don't care about being able to have some sort of partial union
possible with the usage of intersection types,
because it seems the machinery in the engine which makes null work,
should
also allow any standard PHP types as those are part of a bitflag and
handling variance with them seems to work just fine...

But for the love of god, this proposed syntax is horrendous, saying
?X&Y is
unambiguous is disingenuous.
It can either mean (?X)&Y = (X|null)&Y or ?(X&Y) = (X&Y)|null, the
former
one being bogus as null&Y is an impossible type, something which should
error out to point out a potential bug in the same way we do for
redundant
types that we know at compile time.
And if we allow this syntax then we really should be allowing ?A|B
which is
dumb.
(and no ?X&Y is NOT something I consider forward compatible when it is
just
going to become one more edge case we need to maintain because people
have
no patience).

If ?(X&Y) is allowed then ?(A|B) should also be allowed, and that needs
an
RFC for sure due to the controversy it had in the union type RFC.

The only remaining sensible choice is (X&Y)|null / null|(X&Y), but as I
said above if the machinery for null is there it must mean the machinery
for int/string/array/float/bool is also there, and frankly being able
to do
something like (Traversable&Countable)|array is also extremely valuable,
maybe even more than nullability, but in any case this is going to be
confusing for end-users why only null (or standard PHP types) can be
combined in a union with intersection types.

That's one reason why it's only pure intersection types, if I had more
time
(or for crying out loud somebody would have paid me) to work on this I
would have loved to get full composite types working.

And I find it frankly insulting that in the four month this RFC has been
published for discussion, with multiple push backs for voting due to
bugs
and me wanting that people know what implementation is - for the most
part

• going to land in php-src, this specific point has not been raised.
  It just feels like you are pissing on 6+ months of unpaid work I did
  because it doesn't suit your needs, and you just realised that and so
  decided to throw a wrench into a carefully crafted RFC to "fix" it by
  using
  a Twitter mob to put pressure on us/me.

Maybe this topic didn't come up because for nearly everyone else "Pure
Intersection Types" means what it says on the can, moreso that in the
RFC
the following line:

This means it would not be possible to mix intersection and union
types
together such as A&B|C, this is left as a future scope
makes it clear, and most voters also understood that '?' is not a type
"flag" but is syntactic sugar for 'null|'.

There are plenty of issues with the implementation, from the whack
parser
hack, the non support for static/parent/self, to the complexity of the
variance code, but I made all of those clear because they made me
uncomfortable with the implementation.
So if you are going to force this crappy syntax, then I'd rather axe
this
feature completely (and nobody can use/play with it) then have
something I
do not accept, nor are forced to accept because of a vote, land in core
making PHP even more of an inconsistent joke.

Hey George,

I don't think there's been any malicious intent here -- it was obvious to
you and I that not allowing unions implies not allowing nullability, but I
can see how people less familiar with our type system implementation would
not make that connection. After all, we do provide the separate ?T syntax,
even if it is an internal alias for T|null.

It's an unfortunate fact of the RFC process that concerns are sometimes
only raised when voting starts and people start looking at the
implementation -- or in this case, when they test the implementation after
it has landed...

In any case, I think it's pretty clear by now that there are some fairly
strong opinions both on what the syntax for this should be (between ?X&Y,
?(X&Y), (X&Y)|null and X&Y|null, all of which have reasonable arguments
for
and against) and whether we should have this special case at all. I'm not
sure we will be able to reach a sufficient consensus in this discussion.

For that reason, I think this change should go through the RFC process. We
can grant this an exemption from the feature freeze (as a clarification of
an accepted proposal), but it should still go through the process.

Regards,
Nikita

If RMs and everyone else is okay for this being handled post feature freeze
via an RFC,
I am fine with it too.

Best regards

George P. Banyard

Le mar. 20 juil. 2021 à 14:41, Joe Watkins krakjoe@gmail.com a écrit :

Agree, an RFC looks like the only way.

This is not worth delaying a release for, nor is it worth postponing the
feature freeze date.

It seems reasonable to fix this after freeze, would prefer to reach
consensus before RC stage.

Cheers
Joe

On Mon, Jul 19, 2021 at 8:16 PM G. P. B. george.banyard@gmail.com
wrote:

On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier <
guilliam.xavier@gmail.com>
wrote:

On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas <
nicolas.grekas@gmail.com

wrote:

https://github.com/php/php-src/pull/7259

Great! Thanks! Interesting how it works out-of-the-box with just this
addition in Zend/zend_language_parser.y:

 type_expr:
  type { $$ = $1; }
  | '?' type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; }
  | union_type { $$ = $1; }
  | intersection_type { $$ = $1; }
+ | '?' intersection_type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; }
 ;

On Mon, Jul 19, 2021 at 5:09 PM Dan Ackroyd Danack@basereality.com
wrote:

nicolas-grekas wrote on the PR:

?X&Y cannot be confused with

It confused me. A compiler might understand it, but as a human I
have
trouble understanding it.

Trowski wrote:

The syntax should be either ?(X&Y) or (X&Y)|null

Non-ambiguous syntax is much better than ambiguous syntax.

Maybe it's just a matter of habit?
For instance I got used to seeing things like !$x = f() (e.g. if (!$x = f()) { throw /*...*/; } /* use $x */) because some CS consider
explicit
parentheses in !($x = f()) redundant (as PHP has a special case that
"overrides" the normal precedence (!$x) = f() which would be an
error).
If you first consider X&Y as a type "unit", then it makes sense to
make
it "nullable" by prefixing it with ?, I think?

But this discussion is moot for 8.1.

This limitation might make intersection types not be considered
usable
by some projects, but the feature freeze is today.

Which can also be reversed: "The feature freeze is today, but this
limitation might make intersection types not be considered usable by
some
projects"? (playing devil's advocate, I don't master the process)

Regards,

--
Guilliam Xavier

Since when is usability for a specific project a consideration an RFC
needs
to have?
If Symfony can't use it in its current state tough luck,
I'm sure plenty of other projects can, especially now that using 'new
Class' is possible as a default object value.

I frankly don't care about being able to have some sort of partial union
possible with the usage of intersection types,
because it seems the machinery in the engine which makes null work,
should
also allow any standard PHP types as those are part of a bitflag and
handling variance with them seems to work just fine...

But for the love of god, this proposed syntax is horrendous, saying
?X&Y is
unambiguous is disingenuous.
It can either mean (?X)&Y = (X|null)&Y or ?(X&Y) = (X&Y)|null, the
former
one being bogus as null&Y is an impossible type, something which should
error out to point out a potential bug in the same way we do for
redundant
types that we know at compile time.
And if we allow this syntax then we really should be allowing ?A|B
which is
dumb.
(and no ?X&Y is NOT something I consider forward compatible when it is
just
going to become one more edge case we need to maintain because people
have
no patience).

If ?(X&Y) is allowed then ?(A|B) should also be allowed, and that needs
an
RFC for sure due to the controversy it had in the union type RFC.

The only remaining sensible choice is (X&Y)|null / null|(X&Y), but as I
said above if the machinery for null is there it must mean the machinery
for int/string/array/float/bool is also there, and frankly being able
to do
something like (Traversable&Countable)|array is also extremely valuable,
maybe even more than nullability, but in any case this is going to be
confusing for end-users why only null (or standard PHP types) can be
combined in a union with intersection types.

That's one reason why it's only pure intersection types, if I had more
time
(or for crying out loud somebody would have paid me) to work on this I
would have loved to get full composite types working.

And I find it frankly insulting that in the four month this RFC has been
published for discussion, with multiple push backs for voting due to
bugs
and me wanting that people know what implementation is - for the most
part

• going to land in php-src, this specific point has not been raised.
  It just feels like you are pissing on 6+ months of unpaid work I did
  because it doesn't suit your needs, and you just realised that and so
  decided to throw a wrench into a carefully crafted RFC to "fix" it by
  using
  a Twitter mob to put pressure on us/me.

Maybe this topic didn't come up because for nearly everyone else "Pure
Intersection Types" means what it says on the can, moreso that in the
RFC
the following line:

This means it would not be possible to mix intersection and union
types
together such as A&B|C, this is left as a future scope
makes it clear, and most voters also understood that '?' is not a type
"flag" but is syntactic sugar for 'null|'.

There are plenty of issues with the implementation, from the whack
parser
hack, the non support for static/parent/self, to the complexity of the
variance code, but I made all of those clear because they made me
uncomfortable with the implementation.
So if you are going to force this crappy syntax, then I'd rather axe
this
feature completely (and nobody can use/play with it) then have
something I
do not accept, nor are forced to accept because of a vote, land in core
making PHP even more of an inconsistent joke.

Hey George,

I don't think there's been any malicious intent here -- it was obvious to
you and I that not allowing unions implies not allowing nullability, but I
can see how people less familiar with our type system implementation would
not make that connection. After all, we do provide the separate ?T syntax,
even if it is an internal alias for T|null.

It's an unfortunate fact of the RFC process that concerns are sometimes
only raised when voting starts and people start looking at the
implementation -- or in this case, when they test the implementation after
it has landed...

In any case, I think it's pretty clear by now that there are some fairly
strong opinions both on what the syntax for this should be (between ?X&Y,
?(X&Y), (X&Y)|null and X&Y|null, all of which have reasonable arguments
for
and against) and whether we should have this special case at all. I'm not
sure we will be able to reach a sufficient consensus in this discussion.

For that reason, I think this change should go through the RFC process. We
can grant this an exemption from the feature freeze (as a clarification of
an accepted proposal), but it should still go through the process.

Thanks Nikita, Joe and the others for opening the possibility of a late
RFC. I'm going to write one down asap!

Nicolas

nicolas-grekas wrote on the PR:

?X&Y cannot be confused with

It confused me. A compiler might understand it, but as a human I
have
trouble understanding it.

I think ?X&Y would be a pretty poor syntax choice, as it's ambiguous as
many others said: (X|null)&(Y) vs. (X&Y)|null.

What hasn't been proposed, yet, is ?X&?Y, so requiring either all or none
of the types being nullable.

Best,
Niklas

From the look of the syntax I would prefer it not to land on 8.1 at all,
which gives us another year to think of any syntax less aggressive to the
eyes.

One of the things I loved about the Pure Intersection RFC was that it
avoided the discussion around parenthesis on type declaration altogether.
Maybe if a type alias is proposed before mingling Union and Intersection,
then it's less of an aggressive syntax.

Type T = (X&Y)|Z|null

I don't know if anyone has offered this before, but if making an exception
for nullable Intersection is on the table, what about putting the null sign
at the end?

X&Y&Z?

It doesn't seem ambiguous because PHP defines ?X as nullable X. It doesn't
seem obvious what the ? is doing at the end but at least it doesn't seem
ambiguous.