Hacker News Reader

Comment by bufferoverflow | Hacker News Reader

> and false as standalone types

That's just wrong. Boolean is the type. False is just one possibile value of that type.

It's for backwards compatibility with functions that return either the expected value (maybe an array or a string) or false (never true). So you can use it in a union like `foo(): string|false {}`. In that sense, it's not a boolean because it will only ever be a string or false.

That makes sense, though you would want a linter or something to check that callers are doing "=== false" and not "== false", since falsy (but not false) values would match the latter.

If you're using `==` in 2022 without testing or linting, this would be the least of your problems. Also, with the strict_types declaration, it wouldn't be coerced.

" == false" is sprinkled all over some pretty popular products, like Wordpress.

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.

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.

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.

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

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

[2] https://wiki.php.net/rfc/null-false-standalone-types

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.

> 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).

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.

What else do you expect, PHP has its roots in a bunch of wrappers around C functions with in-band error signaling. Those functions are like grandpa's old watch that you just can't bring yourself to throw away even though it doesn't match any of your new outfits. Mama WordPress would be mad. :)

I appreciate the humor.

On a little more serious note, Perl is an earlier language and even more closely tied to C tradition. Many (but not all) of its built-ins and library functions and methods return undef rather than 0 for failure.

PHP functions don't return 0, either. They return `false` which is easy to distinguish from other false-ish values using the `===` operator. They're still overloading `false` with failure, of course, but it would be unfair to say that PHP conflates all the false-ish values.

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

Isn't this an announcement about introducing this and other changes into the language now?

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.

> That's just wrong. Boolean is the type. False is just one possibile value of that type.

Having false and true be singleton types is perfectly cromulent.

That's how Smalltalk has been doing it for 40 years, and why it can do without control structures:

    Boolean subclass: False [
        ifTrue: trueBlock ifFalse: falseBlock [
            ^falseBlock value
        ]
        "..."


    Boolean subclass: True [
        ifTrue: trueBlock ifFalse: falseBlock [
            ^trueBlock value
        ]
        "..."

"false" is a literal type in TypeScript, Coq, Agda, Idris, Scala.

False in Coq/Agda/Idris is a zero type, not a unit type. True is a unit type. Now PHP is making the opposite choice. Confused enough?

Reply on news.ycombinator.com