Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78169
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <9ADD6AAC-A402-44B6-B9AA-A3F5F8A225AD@fb.com>
Date: Tue, 21 Oct 2014 02:17:21 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6C259842-9CA7-4058-9929-59CC3C9EA503@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <9ADD6AAC-A402-44B6-B9AA-A3F5F8A225AD@fb.com>
To: Josh Watzman <jwatzman@fb.com>
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 21 Oct 2014, at 02:07, Josh Watzman <jwatzman@fb.com> wrote:
>=20
> 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=92t.

Why isn=92t 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=92re only using FALSE here.

>> 	=95 If strict type hinting were added, they would fail for a =
nullable typehint
>=20
> 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=92s also no precedent for =
using them.

Returning NULL would mean it=92s validate for a nullable type hint, =
which is bad, but also, NULL signifies a lack of a value. There isn=92t =
a lack of a value, there=92s no value. We should not use NULL here.

>> 	=95 FALSE is a traditional error value in PHP
>=20
> 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=92s not a =93weird second kind of null=94, it=92s 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=92t 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/