> Le 23 sept. 2019 à 22:14, Benjamin Morel <benjamin.mo...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
