4 ms·

I 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 "

I 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 5y ago
Good design choice for new lang. What about when there is 20+ years of history? Can't just move fast and break things.
- cestith 5y ago
  Isn't this an announcement about introducing this and other changes into the language now?
  - masklinn 5y ago
    It’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 5y ago
It 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 5y ago
  This 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 5y ago
    It 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 5y 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_ 5y ago
    Introducing `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 5y ago
  Oh, 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.

djbusby 5y ago

Good design choice for new lang. What about when there is 20+ years of history? Can't just move fast and break things.

cestith 5y ago
Isn't this an announcement about introducing this and other changes into the language now?
- masklinn 5y ago
  It’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 5y ago

It 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 5y ago
This 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 5y ago
  It 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 5y 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_ 5y ago
  Introducing `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 5y ago
Oh, 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.