Hacker News Reader

Comment by kijin | Hacker News Reader

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.

View on HN

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

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

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

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.

Reply on news.ycombinator.com