Re: [RFC] Union Types v2

> Le 23 sept. 2019 à 22:14, Benjamin Morel <benjamin.morel@gmail.com> a écrit : > > > So although true as a type does not have the same historical background as > false, it does seem that it's being used by enough packages to be worth > considering; what do you think? > Considering to support true will raise several questions. They can be resolved, of course, but that will put more design decisions over the shoulders of the Union Types RFC: * The first one, of course, is why the list of possible literal values is *still* restricted. Because now you’ll want to use other literal values, e.g., 0 or "some-string". * Another issue is the relation between Foo | false | true and Foo | bool: whether the first form is allowed; whether they are equivalent w.r.t. variance rules; how casting to true | false works (or doesn’t work) under declare(strict_types=0). * Also, if we support more than two literal values as types (and especially when not all of them indicate failure), we’ll want more strongly to have them to appear as standalone types, e.g., true | null; and then, naturally, just true and just null. At this point, the question will be raised whether it is desirable to have both null and void as return types. ------------- 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). —Claude