Re: [RFC] Safe Casting Functions

> On 21 Oct 2014, at 02:07, Josh Watzman <jwatzman@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/