Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107351
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Claude Pache <claude.pache@gmail.com>,
 Benjamin Morel <benjamin.morel@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c8EvfFPqjRJjJ3T-qTfLiWn7aZzCrGpk7R3yNFLT1qWjQ@mail.gmail.com>
 <CAF+90c8CvL3xvUpX1o2RH2Jjjj=fW5XbrLS5tkc6FdmS4cC+eQ@mail.gmail.com>
 <CAG9XoMRuvecyBQfB7fYEkO2=evdZ1wBHYVWioOcOMTJyObe2bQ@mail.gmail.com>
 <1544E25D-630F-4E02-BCF1-1A0DEF1EBD60@gmail.com>
 <CAESVnVr5xyZW25GFcKOcOhEHtCtOj6jbmzYnCzCcaApNO8m+jQ@mail.gmail.com>
 <CAF+90c9YVSDGZ9K=Me5fOVBnnCxXMaSqkOdNiqO0Vh05rrho2w@mail.gmail.com>
Message-ID: <edf8d38c-1b42-c053-1f1e-d4e392f7864c@telia.com>
Date: Mon, 30 Sep 2019 12:18:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c9YVSDGZ9K=Me5fOVBnnCxXMaSqkOdNiqO0Vh05rrho2w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Union Types v2
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2019-09-26 kl. 10:06, skrev Nikita Popov:

> On Tue, Sep 24, 2019 at 10:06 PM Sara Golemon <pollita@php.net> wrote:
>
>> On Tue, Sep 24, 2019 at 12:24 PM Claude Pache <claude.pache@gmail.com>
>> wrote:
>>> The choice of supporting precisely the two literal values `null` and
>> `false`
>>> is not arbitrary: They are the two values that are the most often used as
>>> sentinel values (for indicating failure or absence). It is true that
>> `true` is
>>> also sometimes used as sentinel value (more rarely and not among the
>>> internal functions), but the same can be said of other literal values
>>> (one of your examples includes `0`).
>>>
>> While I personally think `false` makes sense as an allowed "type", I also
>> don't want to see the union types RFC get held up on such a tiny detail.
>>
>> I would propose either of the following alternatives:
>> 1/ Remove `false` from the proposal. It can always be added at a later
>> time, but not taken away.
>> 2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
>> also be subject to a 2/3 majority in order to pass.
>>
>> -Sara
>>
> This RFC is currently held up by a lack of implementation. Once that is
> done, the RFC will go forward as-is (barring any novel concerns). Because I
> consider it an important part of the overall proposal (*), I will neither
> remove the false type, nor split it into a separate vote. People may vote
> against the whole RFC if they disagree with this aspect, or any other
> aspect of the proposal.
>
> Regards,
> Nikita
>
> (*) While certainly not the primary reason for why we should support union
> types, the reason why I brought this proposal forward at this time
> specifically, is that the lack of union types is a blocker for my pet
> project of providing comprehensive type annotations for internal functions.
> Supporting "false" is strictly necessary for this purpose, because it is
> part of nearly all unions as far as internal functions are concerned.

Hi Nikita,

Given the feedback on 23/9 from B Morel regarding
occurrence of true as a return value, would you then
consider adding true as a valid return type in unions?

r//Björn L