4 ms·
Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In t
by Dragony 4y ago
Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.
- cestith 4y agoI don't think the argument is against unit types. I think the argument is against calling one "false", and I agree. If you're going to have a reserved keyword "false", have "true" and "false" as Boolean. If you want a unit type to mean "failed", "failure", "incomplete", or something, use one of those words.
- djbusby 4y agoGood design choice for new lang. What about when there is 20+ years of history? Can't just move fast and break things.
- cestith 4y agoIsn't this an announcement about introducing this and other changes into the language now?
- masklinn 4y agoIt’s really an announcement about the formalisation of existing API patterns: returning FALSE on failure (regardless of the “success” type) is part of many old php apis, this change allows properly typing those.
- kijin 4y agoIt actually makes a bit of sense if you think of Bool as a class instead of a primitive type, and True and False as subclasses of Bool. So a function can either declare its return type as "bool", or as the more specific "false". True is simply not implemented. PHP isn't exacly an "everything is an object" language, but it's been slowly moving in that direction for years, replacing most callables, resources, etc. with corresponding objects. I wouldn't be surprised if the designers are approaching this issue with an object-oriented mindset, though it still feels wrong to make an exception for only one half of a boolean pair.
- steve_adams_86 4y agoThis works fine in TypeScript. You can specify a type as boolean, true, or false, and it works exactly as you’d expect. I don’t see an issue with doing the same in PHP
- cestith 4y agoIt would not surprise me any to have a Boolean type and have both true and false as restricted subtypes of that. However, in this case of it being used primarily as a return type for failure in a function call, I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound rather than creating a type specific to the error condition.
- masklinn 4y ago> I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound It’s not really conflation when php has been doing that since forever as it originally was little more than a thin shim over C (you can see that in lots of older APIs e.g. the mysql_ stuff is straight transcribed from the C library).
- bow_ 4y agoIntroducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1]. The introduction of the RFC [2] also still mentions `false` is of type bool: > null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool. But why call it bool if `true` is not a standalone type too? [1] https://docs.python.org/3/library/typing.html#typing.Literal https://docs.python.org/3/library/typing.html#typing.Literal [2] https://wiki.php.net/rfc/null-false-standalone-types https://wiki.php.net/rfc/null-false-standalone-types
- cestith 4y agoOh, it makes sense. It would just make more sense to me if the unit type for an error or failure was called "error" or "failure". They're sort of overloading the idea of true/false here with the historical baggage of returning a value that evaluates to false-ish for failure, then codifying that in a new type rather than taking the chance to make the new type a clean break from that in-band concept.