Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Fleshgrinder]

On 4/26/2016 9:40 PM, Levi Morrison wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

On Tue, Apr 26, 2016 at 1:34 PM, Fleshgrinder  wrote:
> On 4/26/2016 9:13 PM, Bob Weinand wrote:
>> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Fleshgrinder]

On 4/26/2016 9:13 PM, Bob Weinand wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Bob Weinand]

> Am 26.04.2016 um 19:41 schrieb Niklas Keller :
> 
> 2016-04-26 19:33 GMT+02:00 Bob Weinand  >:
> > Am 26.04.2016 um 19:00 schrieb Niklas Keller  > >:
> >
> > 2016-04-26 16:58 GMT+02:00 Bob Weinand  > >:
> >
> >> 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) {}.

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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Niklas Keller]

2016-04-26 19:33 GMT+02:00 Bob Weinand :

> > Am 26.04.2016 um 19:00 schrieb Niklas Keller :
> >
> > 2016-04-26 16:58 GMT+02:00 Bob Weinand :
> >
> >> 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) {}.

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Bob Weinand]

> Am 26.04.2016 um 19:00 schrieb Niklas Keller :
> 
> 2016-04-26 16:58 GMT+02:00 Bob Weinand :
> 
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

On Tue, Apr 26, 2016 at 11:20 AM, Levi Morrison  wrote:
> On Tue, Apr 26, 2016 at 11:00 AM, Niklas Keller  wrote:
>> 2016-04-26 16:58 GMT+02:00 Bob Weinand :
>>>
>>> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

On Tue, Apr 26, 2016 at 11:00 AM, Niklas Keller  wrote:
> 2016-04-26 16:58 GMT+02:00 Bob Weinand :
>>
>> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Niklas Keller]

2016-04-26 16:58 GMT+02:00 Bob Weinand :

> 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.

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Tom Worster]

On 4/26/16 10:58 AM, Bob Weinand wrote:

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Tom Worster]

On 4/26/16 12:21 PM, Christoph Becker wrote:

On 26.04.2016 at 16:24, Dmitry Stogov wrote:


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"
(), 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Christoph Becker]

On 26.04.2016 at 16:24, Dmitry Stogov wrote:

> 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"
(), which apparently is still
under discussion.

Will voting on this RFC also start tomorrow?

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dominic Grostate]

Balls.. Void my last comment..
On 26 Apr 2016 4:42 p.m., "Dominic Grostate" <codekest...@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.
> On 26 Apr 2016 4:07 p.m., "Joe Watkins" <pthre...@pthreads.org> wrote:
>
>> 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
>>
>> On Tue, Apr 26, 2016 at 3:53 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>> > "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.l...@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
>> >
>> > On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> > >
>> > >
>> > > On 04/26/2016 05:19 PM, Bob Weinand wrote:
>> > >>>
>> > >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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 t

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dominic Grostate]

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.
On 26 Apr 2016 4:07 p.m., "Joe Watkins" <pthre...@pthreads.org> wrote:

> 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
>
> On Tue, Apr 26, 2016 at 3:53 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
> > "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.l...@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
> >
> > On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> > >
> > >
> > > On 04/26/2016 05:19 PM, Bob Weinand wrote:
> > >>>
> > >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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 (

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Joe Watkins]

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

On Tue, Apr 26, 2016 at 3:53 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> "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.l...@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
>
> On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> >
> >
> > On 04/26/2016 05:19 PM, Bob Weinand wrote:
> >>>
> >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
> >>
> >> 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 g

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

"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.l...@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

On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On 04/26/2016 05:19 PM, Bob Weinand wrote:
>>>
>>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>>
>> 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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Bob Weinand]

> Am 26.04.2016 um 16:47 schrieb Levi Morrison <morrison.l...@gmail.com>:
> On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com 
> <mailto:dmi...@zend.com>> wrote:
>> 
>> On 04/26/2016 05:19 PM, Bob Weinand wrote:
>>>> 
>>>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>>> 
>>> 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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On 04/26/2016 05:19 PM, Bob Weinand wrote:
>>>
>>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>>
>> 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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Bob Weinand]

> Am 26.04.2016 um 16:30 schrieb Dmitry Stogov <dmi...@zend.com>:
> On 04/26/2016 05:19 PM, Bob Weinand wrote:
>>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>> 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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

On 04/26/2016 05:19 PM, Bob Weinand wrote:

Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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

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







--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

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.

On 04/26/2016 05:13 PM, Joe Watkins wrote:

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 <dmi...@zend.com 
<mailto:dmi...@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.l...@gmail.com
<mailto:morrison.l...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Joe Watkins]

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

On Tue, Apr 26, 2016 at 3:20 PM, Joe Watkins <pthre...@pthreads.org> wrote:

> 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
>
> On Tue, Apr 26, 2016 at 3:19 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
>>
>> > Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>>
>> 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
>
>
>

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Joe Watkins]

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

On Tue, Apr 26, 2016 at 3:19 PM, Bob Weinand <bobw...@hotmail.com> wrote:

>
> > Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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
>
> 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

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Bob Weinand]

> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov <dmi...@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.l...@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

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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

On 04/26/2016 04:57 PM, Levi Morrison wrote:

On Tue, Apr 26, 2016 at 7:33 AM, Dmitry Stogov  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.

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.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Joe Watkins]

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 <dmi...@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.l...@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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

On Tue, Apr 26, 2016 at 7:33 AM, Dmitry Stogov  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.

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Patch for Union and Intersection Types

[Dmitry Stogov]

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.l...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Patch for Union and Intersection Types

[Levi Morrison]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php