Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107324
MIME-Version: 1.0
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>
In-Reply-To: <CAESVnVr5xyZW25GFcKOcOhEHtCtOj6jbmzYnCzCcaApNO8m+jQ@mail.gmail.com>
Date: Thu, 26 Sep 2019 10:06:00 +0200
Message-ID: <CAF+90c9YVSDGZ9K=Me5fOVBnnCxXMaSqkOdNiqO0Vh05rrho2w@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Claude Pache <claude.pache@gmail.com>, Benjamin Morel <benjamin.morel@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007332660593703ed5"
Subject: Re: [PHP-DEV] [RFC] Union Types v2
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000007332660593703ed5
Content-Type: text/plain; charset="UTF-8"

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.

--0000000000007332660593703ed5--