[RFC] Patch for Union and Intersection Types

8 years ago by Levi Morrison — view source

unread

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).
This patch adds null, true and false for type declarations.
This patch includes conversion rules for weak types.
It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

8 years ago by Dmitry Stogov — view source

unread

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

8 years ago by Levi Morrison — view source

unread

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

Dmitry,

I agree that union types and nullable types should be voted at the
same time. Union types is a large RFC and didn't have an
implementation until now. I think it is important that we have an
implementation to experiment wotj. I hope you can see how having an
implementation to experiment with is essential for both RFCs.

Please do not move any type related RFCs to voting; I am not
attempting to sabatoge nullable types. Please do not make such
accusations.

Levi Morrison

8 years ago by Dmitry Stogov — view source

unread

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.
Dmitry,

I agree that union types and nullable types should be voted at the
same time. Union types is a large RFC and didn't have an
implementation until now. I think it is important that we have an
implementation to experiment wotj. I hope you can see how having an
implementation to experiment with is essential for both RFCs.

Please do not move any type related RFCs to voting; I am not
attempting to sabatoge nullable types. Please do not make such
accusations.

Levi Morrisont
Your "Nullable Types" RFC don't have up to date implementation. You took
ownership on two competing RFCs, but make preference to one.
In our conversation, I took your point 3 times (delaying Nullable in
2015, delaying my RFC for a week (while you have time), sending your RFC
instead of mine, because they proposed almost the same).

I think, it's going to be fair, if now you take my point.

I don't like to argue. You got what you liked.
Now "Union Types" and "Nullable Types" should compete in fair way.

Thanks. Dmitry.

8 years ago by Joe Watkins — view source

unread

Afternoon Dmitry,

I started the implementation of this because unions and nullables

appears to be in my way (typed properties).

At no point did Levi request an implementation. I decided, selfishly,

to provide one because it's in my way, and we've been waiting so long
already.

There is no conspiracy.

I would actually like it if nullable types came first, I would have

preferred not to have my work on typed properties stopped also.

We don't always get what we want :)

Cheers
Joe

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time
for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be
voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

8 years ago by Dmitry Stogov — view source

unread

Hi Joe,

At first, I'm glad this implementation is ready.
At least it's possible to analyze its profs and cons.
I'm also sure that both RFCs have their opponents and advocates.

Now, I just like to make the final voting fair.

Thanks. Dmitry.

Afternoon Dmitry,

I started the implementation of this because unions and nullables

appears to be in my way (typed properties).

At no point did Levi request an implementation. I decided,

selfishly, to provide one because it's in my way, and we've been
waiting so long already.

There is no conspiracy.

I would actually like it if nullable types came first, I would

have preferred not to have my work on typed properties stopped also.

We don't always get what we want :)

Cheers
Joe

On Tue, Apr 26, 2016 at 2:33 PM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to
win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness
(or/and stupidity) allowed you  to pass your version for common
discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both
should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.


________________________________________
From: Levi Morrison <morrison.levi@gmail.com
<mailto:morrison.levi@gmail.com>>
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch
for union types][1]. Please go download it and experiment with it.

A few things to note:

  * This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as `Array | (Countable & Traversable)`.
  * This patch adds `null`, `true` and `false` for type declarations.
  * This patch includes conversion rules for weak types.
  * It does not have short-hand for unions with null (`?Foo` being
`Foo | Null`)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

  [1]: https://github.com/php/php-src/pull/1887

8 years ago by Christoph Becker — view source

unread

At first, I'm glad this implementation is ready.
At least it's possible to analyze its profs and cons.
I'm also sure that both RFCs have their opponents and advocates.

Now, I just like to make the final voting fair.

I'm a bit confused, as there is actually a third related RFC, namely Tom
Worster's "Nullable Return Type Declaration"
(https://wiki.php.net/rfc/nullable_returns), which apparently is still
under discussion.

Will voting on this RFC also start tomorrow?

--
Christoph M. Becker

8 years ago by Tom Worster — view source

unread

At first, I'm glad this implementation is ready.
At least it's possible to analyze its profs and cons.
I'm also sure that both RFCs have their opponents and advocates.

Now, I just like to make the final voting fair.

I'm a bit confused, as there is actually a third related RFC, namely Tom
Worster's "Nullable Return Type Declaration"
(https://wiki.php.net/rfc/nullable_returns), which apparently is still
under discussion.

Will voting on this RFC also start tomorrow?

I would like to know too.

I would also prefer if the discussion of voting options (decision tree?)
would happen under a suitable Subject line. I didn't know this
discussion was here until Christoph cc-ed (thanks, Christoph). I'm
probably not alone in having missed all this.

Tom

8 years ago by Bob Weinand — view source

unread

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out before starting this RFC (as it didn't make it in time for going into 7.0 too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now, he has time to manage things and we could move ahead quickly and write the patch up.

I'd like to hold first a formal (and binding) vote on whether "null |" or "?" should be used (in case both RFCs pass). Rushing things through right now might just us ending up with semantics the vast majority dislikes.

Thanks,
Bob

8 years ago by Joe Watkins — view source

unread

Fully agree, I think we should move ahead with the nullable question first,
and swiftly.

Happy for them to go to vote, tomorrow, if that was serious.

Cheers
Joe

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into 7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now,
he has time to manage things and we could move ahead quickly and write the
patch up.

I'd like to hold first a formal (and binding) vote on whether "null |" or
"?" should be used (in case both RFCs pass). Rushing things through right
now might just us ending up with semantics the vast majority dislikes.

Thanks,
Bob

8 years ago by Joe Watkins — view source

unread

Dmitry,

Just to be clear, the nullable support in the implementation of

union/intersection is not a suggestion, the patch will conform to whatever
is decided by nullable types RFC.

That was always the intention.

Cheers
Joe

Fully agree, I think we should move ahead with the nullable question
first, and swiftly.

Happy for them to go to vote, tomorrow, if that was serious.

Cheers
Joe

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into 7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now,
he has time to manage things and we could move ahead quickly and write the
patch up.

I'd like to hold first a formal (and binding) vote on whether "null |" or
"?" should be used (in case both RFCs pass). Rushing things through right
now might just us ending up with semantics the vast majority dislikes.

Thanks,
Bob

8 years ago by Dmitry Stogov — view source

unread

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out before starting this RFC (as it didn't make it in time for going into 7.0 too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now, he has time to manage things and we could move ahead quickly and write the patch up.
I know, we all like to make our best for PHP.
Sorry, if I was too emotional.
I'd like to hold first a formal (and binding) vote on whether "null |" or "?" should be used (in case both RFCs pass). Rushing things through right now might just us ending up with semantics the vast majority dislikes.
I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

8 years ago by Bob Weinand — view source

unread

Am 26.04.2016 um 16:30 schrieb Dmitry Stogov dmitry@zend.com:

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out before starting this RFC (as it didn't make it in time for going into 7.0 too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now, he has time to manage things and we could move ahead quickly and write the patch up.
I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

Yeah, you were, but no worries ;-)

I'd like to hold first a formal (and binding) vote on whether "null |" or "?" should be used (in case both RFCs pass). Rushing things through right now might just us ending up with semantics the vast majority dislikes.
I didn't exactly get, what do you propose. One RFC with voting for "Nullable" or "Union"?

The matter is a bit complicated, as Foo | null has a bit a dependency on unions in general.

We basically need a vote on:

Regardless of unions patch, use ?Foo
If unions pass, use Foo | null
If unions fail, use ?Foo, else no nullables at all
No nullables at all (wins if more than one third of vote)

For the other choices, majority wins.

If we end up having two RFCs with each reaching two thirds (?Foo is a nice concept, yes, please! and simultaneously Foo | Bar is a nice concept, please yes!), we risk having two different RFCs implementing the same in different ways, which may end up in a fight what should be done.
We really should clarify what exactly we vote on, before doing any competing votes and not knowing what to do in a case where both RFCs pass. [as the one RFC may cannibalize the other or people eventually start voting yes on both.]

Thanks,
Bob

Thanks. Dmitry.

Thanks,
Bob

8 years ago by Levi Morrison — view source

unread

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into 7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now,
he has time to manage things and we could move ahead quickly and write the
patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null |" or
"?" should be used (in case both RFCs pass). Rushing things through right
now might just us ending up with semantics the vast majority dislikes.

I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: ?Array | Travsersable as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression Foo | Null instead of ?Foo, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?

8 years ago by Bob Weinand — view source

unread

Am 26.04.2016 um 16:47 schrieb Levi Morrison morrison.levi@gmail.com:

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into 7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now,
he has time to manage things and we could move ahead quickly and write the
patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null |" or
"?" should be used (in case both RFCs pass). Rushing things through right
now might just us ending up with semantics the vast majority dislikes.

I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: ?Array | Travsersable as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression Foo | Null instead of ?Foo, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?

Yeah, I'd like to not allow ?Foo in any case if union types pass.
If they fail, ?Foo is fine for me.

Bob

8 years ago by Tom Worster — view source

unread

Yeah, I'd like to not allow ?Foo in any case if union types pass.
If they fail, ?Foo is fine for me.

I am persuaded that using the HHVM grammar is best. I personally don't
like but it makes sense.

If the Union RFC would propose only the | grammar and both Nullable RFCs
would propose only ? grammar then the decision process could be
relatively clear:

1 Union
2 Nullable hints and return
3 Nullable return
4 None of the above

Tom

8 years ago by Niklas Keller — view source

unread

2016-04-26 16:58 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it be.

8 years ago by Levi Morrison — view source

unread

2016-04-26 16:58 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it be.

On the contrary, our manual says:

NULL is the only possible value of type null.

And internally it is also a distinct type.

It's been this way for a long time; we just haven't permitted null
as a type declaration because until now it has been useless.

8 years ago by Levi Morrison — view source

unread

2016-04-26 16:58 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it be.

On the contrary, our manual says:

NULL is the only possible value of type null.

And internally it is also a distinct type.

It's been this way for a long time; we just haven't permitted null
as a type declaration because until now it has been useless.

To further expand on why it was previously useless:

function foo(Null $a) {
    return $a;
}

There is only one possibility for this parameter, which is the value
NULL. There is hardly any value to it when you can just write this
instead:

function foo() {
    return NULL;
}

In words: if the only possible value for a parameter is null then it's
not really a parameter; it's just a constant value and doesn't need to
be parameterized.

8 years ago by Bob Weinand — view source

unread

Am 26.04.2016 um 19:00 schrieb Niklas Keller me@kelunik.com:

2016-04-26 16:58 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it be.

I don't want to argue that now, but null most definitely IS a type. It is the null type with a single value, null, whose semantics is to represent the absence of any other value.

There's also plenty of evidence in PHP that null is considered a type: get_type(), https://php.net/null, has it's own is_* function etc.
At least in the PHP ecosystem it is considered its own type. Other type systems may not, but the one of PHP does.

Thus, we are definitely considering it as a type - a question for you: What's the type of the value null then, if not null?

If we wouldn't make a distinction between null and an object (i.e. allow null to be passed to a function(Foo $foo) {}), it could be considered a supervalue of type object. But that's not the case.

Bob

8 years ago by Niklas Keller — view source

unread

2016-04-26 19:33 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Am 26.04.2016 um 19:00 schrieb Niklas Keller me@kelunik.com:

2016-04-26 16:58 GMT+02:00 Bob Weinand bobwei9@hotmail.com:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it
be.

I don't want to argue that now, but null most definitely IS a type. It is
the null type with a single value, null, whose semantics is to represent
the absence of any other value.

There's also plenty of evidence in PHP that null is considered a type:
get_type(), https://php.net/null, has it's own is_* function etc.
At least in the PHP ecosystem it is considered its own type. Other type
systems may not, but the one of PHP does.

Thus, we are definitely considering it as a type - a question for you:
What's the type of the value null then, if not null?

I'd say it's special and doesn't have a type at all. No value, no type.

If we wouldn't make a distinction between null and an object (i.e. allow
null to be passed to a function(Foo $foo) {}), it could be considered a
supervalue of type object. But that's not the case.

If null doesn't have a type, it's clear that it can't be passed to a
function(Foo $foo) {}.

8 years ago by Bob Weinand — view source

unread

Am 26.04.2016 um 19:41 schrieb Niklas Keller me@kelunik.com:

2016-04-26 19:33 GMT+02:00 Bob Weinand <bobwei9@hotmail.com mailto:bobwei9@hotmail.com>:

Am 26.04.2016 um 19:00 schrieb Niklas Keller <me@kelunik.com mailto:me@kelunik.com>:

2016-04-26 16:58 GMT+02:00 Bob Weinand <bobwei9@hotmail.com mailto:bobwei9@hotmail.com>:

Yeah, I'd like to not allow ?Foo in any case if union types pass.

What's the reason for that? To me, null is neither a type nor should it be.

I don't want to argue that now, but null most definitely IS a type. It is the null type with a single value, null, whose semantics is to represent the absence of any other value.

There's also plenty of evidence in PHP that null is considered a type: get_type(), https://php.net/null https://php.net/null, has it's own is_* function etc.
At least in the PHP ecosystem it is considered its own type. Other type systems may not, but the one of PHP does.

Thus, we are definitely considering it as a type - a question for you: What's the type of the value null then, if not null?

I'd say it's special and doesn't have a type at all. No value, no type.

If we wouldn't make a distinction between null and an object (i.e. allow null to be passed to a function(Foo $foo) {}), it could be considered a supervalue of type object. But that's not the case.

If null doesn't have a type, it's clear that it can't be passed to a function(Foo $foo) {}.

There's undefined (= not a value) and there's the value null. We just don't expose undefined to userland. [You see it when accessing undefined variables, which PHP converts to null with a notice for example.]

Null is definitely a value. You can pass it around, reflect on it, assign it etc..
And as it is a value, it also has a type, which is null.

Null is not special, it just has specific behavior, like any other primitive type has. The only special thing is that it's allowed as a default value with function (Foo $foo = null), but this should be somewhen deprecated and removed once we have proper null unions.

If you want to continue arguing, please open a new thread, but don't side-track this thread to much, please.

Bob

8 years ago by Fleshgrinder — view source

unread

There's undefined (= not a value) and there's the value null. We just don't expose undefined to userland. [You see it when accessing undefined variables, which PHP converts to null with a notice for example.]

Null is definitely a value. You can pass it around, reflect on it, assign it etc..
And as it is a value, it also has a type, which is null.

Null is not special, it just has specific behavior, like any other primitive type has. The only special thing is that it's allowed as a default value with function (Foo $foo = null), but this should be somewhen deprecated and removed once we have proper null unions.

If you want to continue arguing, please open a new thread, but don't side-track this thread to much, please.

Bob

Null is a type, no argument there!

Deprecation of null as default value makes no sense, nor does it make
sense to deprecate 42 as default value. ;)

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Levi Morrison — view source

unread

There's undefined (= not a value) and there's the value null. We just don't expose undefined to userland. [You see it when accessing undefined variables, which PHP converts to null with a notice for example.]

Null is definitely a value. You can pass it around, reflect on it, assign it etc..
And as it is a value, it also has a type, which is null.

Null is not special, it just has specific behavior, like any other primitive type has. The only special thing is that it's allowed as a default value with function (Foo $foo = null), but this should be somewhen deprecated and removed once we have proper null unions.

If you want to continue arguing, please open a new thread, but don't side-track this thread to much, please.

Bob

Null is a type, no argument there!

Deprecation of null as default value makes no sense, nor does it make
sense to deprecate 42 as default value. ;)

--
Richard "Fleshgrinder" Fussenegger

I think he meant to post a different case:

function (Foo $foo = null, $concrete_param);

This is based on a conversation I've had with him elsewhere.

8 years ago by Fleshgrinder — view source

unread

I think he meant to post a different case:
function (Foo $foo = null, $concrete_param);
This is based on a conversation I've had with him elsewhere.

Gosh, I know such code. That should result in an error! :P

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Dmitry Stogov — view source

unread

"Foo | null" doesn't make sense without "Union Types".
Voting for one RFC first makes a preference and unfair.

Voting for two different RFCs with 2/3 majority is not good as well.
But this is the best option from my point, in case both pass we may make additional voting with simple majority "Union" or "Nullable" or "Union+Nullable".

Thanks. Dmitry.

8 years ago by Joe Watkins — view source

unread

Dmitry,

"Foo | null" doesn't make sense without "Union Types".

I just said that in a chat room, and someone said "I prefer Bar | null over
?Bar, I find myself missing the ?".

So maybe there is rationale for choosing a syntax for nullable first,
independent of the question of return and params, and unions or
intersections ?

Levi,

Joe seems to just want nullables to have an outcome so it is no longer
blocking typed properties.

I want it to have the right outcome, but yes, basically ... get off my lawn
:D

I am persuaded that Bar | null could be perceived as clearer regardless of
the introduction of multi types, it may be a worthwhile conversation/vote.

Cheers
Joe

"Foo | null" doesn't make sense without "Union Types".
Voting for one RFC first makes a preference and unfair.

Voting for two different RFCs with 2/3 majority is not good as well.
But this is the best option from my point, in case both pass we may make
additional voting with simple majority "Union" or "Nullable" or
"Union+Nullable".

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 17:47
To: Dmitry Stogov
Cc: Bob Weinand; internals; Joe Watkins
Subject: Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being
Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into
7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months… Now,
he has time to manage things and we could move ahead quickly and write
the
patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null |"
or
"?" should be used (in case both RFCs pass). Rushing things through
right
now might just us ending up with semantics the vast majority dislikes.

I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: ?Array | Travsersable as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression Foo | Null instead of ?Foo, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?

8 years ago by Dominic Grostate — view source

unread

Is this RFC going to play nice with Void return types?

If we get unions, then doesn't it follow that the declaration goes as this?

function foo(A | B $val = null): JustChill | void
{}

That's a nullable typehint and a nullable return type surely.

Dmitry,

"Foo | null" doesn't make sense without "Union Types".

I just said that in a chat room, and someone said "I prefer Bar | null over
?Bar, I find myself missing the ?".

So maybe there is rationale for choosing a syntax for nullable first,
independent of the question of return and params, and unions or
intersections ?

Levi,

Joe seems to just want nullables to have an outcome so it is no longer
blocking typed properties.

I want it to have the right outcome, but yes, basically ... get off my lawn
:D

I am persuaded that Bar | null could be perceived as clearer regardless of
the introduction of multi types, it may be a worthwhile conversation/vote.

Cheers
Joe

"Foo | null" doesn't make sense without "Union Types".
Voting for one RFC first makes a preference and unfair.

Voting for two different RFCs with 2/3 majority is not good as well.
But this is the best option from my point, in case both pass we may make
additional voting with simple majority "Union" or "Nullable" or
"Union+Nullable".

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 17:47
To: Dmitry Stogov
Cc: Bob Weinand; internals; Joe Watkins
Subject: Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness (or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both
should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type
expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being
Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to
solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right
now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into
7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months…
Now,
he has time to manage things and we could move ahead quickly and write
the
patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null |"
or
"?" should be used (in case both RFCs pass). Rushing things through
right
now might just us ending up with semantics the vast majority dislikes.

I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: ?Array | Travsersable as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression Foo | Null instead of ?Foo, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?

8 years ago by Dominic Grostate — view source

unread

Balls.. Void my last comment..
On 26 Apr 2016 4:42 p.m., "Dominic Grostate" codekestrel@googlemail.com
wrote:

Is this RFC going to play nice with Void return types?

If we get unions, then doesn't it follow that the declaration goes as this?

function foo(A | B $val = null): JustChill | void
{}

That's a nullable typehint and a nullable return type surely.

Dmitry,

"Foo | null" doesn't make sense without "Union Types".

I just said that in a chat room, and someone said "I prefer Bar | null
over
?Bar, I find myself missing the ?".

So maybe there is rationale for choosing a syntax for nullable first,
independent of the question of return and params, and unions or
intersections ?

Levi,

Joe seems to just want nullables to have an outcome so it is no longer
blocking typed properties.

I want it to have the right outcome, but yes, basically ... get off my
lawn
:D

I am persuaded that Bar | null could be perceived as clearer regardless of
the introduction of multi types, it may be a worthwhile conversation/vote.

Cheers
Joe

"Foo | null" doesn't make sense without "Union Types".
Voting for one RFC first makes a preference and unfair.

Voting for two different RFCs with 2/3 majority is not good as well.
But this is the best option from my point, in case both pass we may make
additional voting with simple majority "Union" or "Nullable" or
"Union+Nullable".

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 17:47
To: Dmitry Stogov
Cc: Bob Weinand; internals; Joe Watkins
Subject: Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov dmitry@zend.com:

hi Levi,

It looks like your "work" on "Nullable Types" RFC was intended to
win
time for this patch and block "Nullable Types" again.
Actually, you have been blocking it for more than a year :(

I'm going to push my own RFC for voting together with "Union Types".

https://wiki.php.net/rfc/nullable_return_types

At least, it has up to date implementation.

We discussed this internally 2-3 weeks ago, and my politeness
(or/and
stupidity) allowed you to pass your version for common discussion.
Now I can see your real reason :(

Both "Union Types" and "Nullable Types" may make sense, and both
should
be voted at the same time.
Tomorrow is time to start voting. Right?

Thanks. Dmitry.

From: Levi Morrison morrison.levi@gmail.com
Sent: Tuesday, April 26, 2016 02:37
To: internals
Subject: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Internals,

Joe Watkins and Bob Weinand have worked out a proof-of-concept
patch
for union types. Please go download it and experiment with it.

A few things to note:

This patch includes intersection types. However, a type
expression
must be either a union type or an intersection type; it doesn't
support both such as Array | (Countable & Traversable).

This patch adds null, true and false for type
declarations.

This patch includes conversion rules for weak types.

It does not have short-hand for unions with null (?Foo being
Foo | Null)

These features (or omitted ones) are not necessarily what will be
voted on. Rather this patch allows us to experiment with these
features in code. This experience should be helpful for us to
solidify
how we actually feel about these features.

I especially would like people to try out the conversion rules for
scalar types as it has been a point of discussion.

Hey Dmitry,

Please, do not accuse us of blocking the nullables. This wasn't
intentional and rather a coincidence that we provided a patch right
now.
First we wanted to concentrate our forces on getting a great 7.0 out
before starting this RFC (as it didn't make it in time for going into
7.0
too as we waited for result on scalar types in general first).
Then, as you're aware Levi had absolutely no time for a few months…
Now,
he has time to manage things and we could move ahead quickly and
write
the
patch up.

I know, we all like to make our best for PHP.
Sorry, if I was too emotional.

I'd like to hold first a formal (and binding) vote on whether "null
|"
or
"?" should be used (in case both RFCs pass). Rushing things through
right
now might just us ending up with semantics the vast majority
dislikes.

I didn't exactly get, what do you propose. One RFC with voting for
"Nullable" or "Union"?

Thanks. Dmitry.

Thanks,
Bob

I believe the intention here is to decide whether we do the short-hand
syntax for nullable types or only the long-form. I can understand the
rationale of not having both or at least dis-allowing the syntax to
mix them. For example, I don't think anyone really likes allowing
this: ?Array | Travsersable as .

However, if the union types RFC does not pass then it seems odd (to me
at least) to use the expression Foo | Null instead of ?Foo, but I
know Bob would like the long-form in all cases, hence why he would
like a vote. Joe seems to just want nullables to have an outcome so it
is no longer blocking typed properties.

Is that a correct summary, Bob and Joe?