> On 21 Oct 2014, at 02:07, Josh Watzman <jwatz...@fb.com> wrote: > > Throwing an exception or even returning NULL seems so much better than > returning "false" -- "false" is a boolean, not an error, and despite some > historical cases of PHP using "false" as a poor person's error code, it > really isn’t.
Why isn’t FALSE an error value? NULL signifies an absence of a value, not a bad value. We use FALSE in a lot of places to indicate an error. Heck, filter_var uses it for errors here. > If you want error codes, use error codes, or use exceptions, but having two > kinds of failure, null vs false, is really confusing. What two kinds of error? We’re only using FALSE here. >> • If strict type hinting were added, they would fail for a nullable >> typehint > > Throwing an exception also addresses this, in a much cleaner way. If you're > worried about strict typing, then returning "false" is even worse, since the > return type of, for example, to_int is now "int | bool" as opposed to > "nullable-int" or "int" (if you throw). Exceptions make chaining more difficult. There’s also no precedent for using them. Returning NULL would mean it’s validate for a nullable type hint, which is bad, but also, NULL signifies a lack of a value. There isn’t a lack of a value, there’s no value. We should not use NULL here. >> • FALSE is a traditional error value in PHP > > Since this is a new function, one that doesn't interoperate in any > complicated way with the existing library or affect BC, this doesn't seem > that important. IMO a language should have one failure/absense-of-value, in > most cases "null", and having a weird second case seems, well, weird. Failure and absence of value are different things and should not use the same value. Otherwise, you are liable to confuse missing data and errors. > If you have more interesting failure cases, just throw an exception, or > return null if you want, don't continue propagating a weird second kind of > null (that isn't actually null, it's a boolean false). It’s not a “weird second kind of null”, it’s a value FALSE. > Also, that we *couldn't* introduce a meaningful to_bool function, even if we > decided we wanted it, indicates to me that returning false is the wrong thing > to do. It would be possible to use a special value in that specific case. Though, again, booleans have their own problems. I don’t see the point in to_bool(). > It's also interesting to look at how other languages handle failures of this > kind. Most imperative languages I know of either throw or return null; in > particular, Python, which has fairly similar type system to PHP in a lot of > ways, throws. Functional languages do more interesting things; Haskell does > something complicated but morally equivalent to returning null. But I'm not > aware of any language which specifically returns false. JavaScript returns NaN here and C sets errno to an error value. PHP uses FALSE, in some respects, like JavaScript uses NaN. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
