Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107326
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>
 <CAF+90c9YVSDGZ9K=Me5fOVBnnCxXMaSqkOdNiqO0Vh05rrho2w@mail.gmail.com>
In-Reply-To: <CAF+90c9YVSDGZ9K=Me5fOVBnnCxXMaSqkOdNiqO0Vh05rrho2w@mail.gmail.com>
Date: Thu, 26 Sep 2019 11:21:07 +0200
Message-ID: <CANS-=pcO=n0MGkouPmSfFs=if5p3Lpo4cGaXfJtrrW3X9-D8Xg@mail.gmail.com>
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>
Content-Type: multipart/alternative; boundary="000000000000b2cf680593714bdd"
Subject: Re: [PHP-DEV] [RFC] Union Types v2
From: kjarli@gmail.com (Lynn)

--000000000000b2cf680593714bdd
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 26, 2019 at 10:06 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> 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,

What if a 'new' type is added specifically to identify this case? Instead
of giving it `int|false`, it could be `int|failed`, where `failed` would
allow a single value only: false. I like it more than naming the return
type `false`. I'm not sure this type should be declarable in user-land,
meaning it's limited to the core and a marker for legacy. `failed` (or name
it whatever) and `false` would still be identical, yet has a more distinct
identification and does not imply there could also a type called `true`.

Figured I'd toss in here as an out-of-the-box idea.

Regards,
Lynn van der Berg

--000000000000b2cf680593714bdd--