On Thu, Sep 26, 2019 at 10:06 AM Nikita Popov <nikita....@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
