Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.145.42 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, "derick@php.net" <derick@php.net>
CC: PHP Internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Safe Casting Functions
Thread-Index: AQHP7LlZiSKK4iJP+UuYlFeFZanGU5w6MpeAgAAC1YCAAR5RgA==
Date: Tue, 21 Oct 2014 18:22:07 +0000
Message-ID: <719B54C7-7048-4C5B-B251-4BCFB3C72643@fb.com>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me>
 <9ADD6AAC-A402-44B6-B9AA-A3F5F8A225AD@fb.com>
 <6C259842-9CA7-4058-9929-59CC3C9EA503@ajf.me>
In-Reply-To: <6C259842-9CA7-4058-9929-59CC3C9EA503@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <381461BC2AA07548AB7EEB9B9052CFB0@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: jwatzman@fb.com (Josh Watzman)

On Oct 20, 2014, at 6:17 PM, Andrea Faulds <ajf@ajf.me> wrote:

>> 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 r=
eturning "false" -- "false" is a boolean, not an error, and despite some hi=
storical cases of PHP using "false" as a poor person's error code, it reall=
y isn=92t.
>=20
> Why isn=92t FALSE an error value? NULL signifies an absence of a value, n=
ot a bad value. We use FALSE in a lot of places to indicate an error. Heck,=
 filter_var uses it for errors here.

FALSE is not an error value because it is already something else. It's alre=
ady a value, it's boolean false. The fact that you couldn't build a reasona=
ble to_bool even if you wanted to, as I as well as others pointed out on th=
is thread, indicates the very real problem with the conflation of purposes =
here. Derick Rethans said it pretty well:

> Then to_bool() whould return false... or true? So hence, it should be=20
> NULL, and that would also be consistent with ext/filter.

You also said:

>> Also, that we *couldn't* introduce a meaningful to_bool function, even i=
f we decided we wanted it, indicates to me that returning false is the wron=
g thing to do.
>=20
> 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_bo=
ol().

Whether or not we actually should add to_bool is a separate issue; we, in p=
rinciple, should be able to cleanly add it, since it's a very natural exten=
sion to what you've already designed here. The fact that, if we used FALSE =
for error that to_bool would have to be a special case, inconsistent with t=
he rest, indicates to me that using FALSE is the wrong thing -- again, it's=
 the conflation of the boolean value FALSE, which already has this meaning,=
 with some error code. It shouldn't be conflated, FALSE should not be an er=
ror return, it means something else.

>> If you want error codes, use error codes, or use exceptions, but having =
two kinds of failure, null vs false, is really confusing.
>=20
> What two kinds of error? We=92re only using FALSE here.

But FALSE *is* a different kind of error as you're trying to use it here, d=
ifferent than NULL which is specifically designed to be an error / lack of =
value. NULL doesn't mean anything else, it's a specially-designated value. =
And if you don't want to use NULL for failure because you don't think this =
is quite the sort of failure that NULL expresses, then throw an exception -=
- FALSE is just totally the wrong thing to return.

>>> 	=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, sinc=
e the return type of, for example, to_int is now "int | bool" as opposed to=
 "nullable-int" or "int" (if you throw).
>=20
> Exceptions make chaining more difficult. There=92s also no precedent for =
using them.

I think the argument about chaining was addressed by someone else. With pre=
cedent, just because there's no precedent doesn't mean we can't start now :=
) They really feel like the right thing to do here and elsewhere, and we ha=
ve to start somewhere.

>>> 	=95 FALSE is a traditional error value in PHP
>>=20
>> Since this is a new function, one that doesn't interoperate in any compl=
icated way with the existing library or affect BC, this doesn't seem that i=
mportant. IMO a language should have one failure/absense-of-value, in most =
cases "null", and having a weird second case seems, well, weird.
>=20
> 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.

But if you want to make that distinction, then you shouldn't use a value th=
at means something else to indicate failure. You should throw an exception.=
 Returning FALSE is liable to replace confusion between missing data and er=
rors with confusion between some other data (i.e., the boolean FALSE) and e=
rrors.

I might also argue that missing the data makes it clear there was an error,=
 and then if someone has a nullable typehint they expressly said they accep=
t a lack-of-int, but an exception seems a much cleaner way to deal with thi=
s anyways.

>> 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).
>=20
> It=92s not a =93weird second kind of null=94, it=92s a value FALSE.

Which is being used as a weird second kind of failure, as opposed to NULL w=
hich is the typical failure lack-of-value, as I argue above.

>> 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 lo=
t 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.
>=20
> JavaScript returns NaN here and C sets errno to an error value. PHP uses =
FALSE, in some respects, like JavaScript uses NaN.

But it probably shouldn't -- NaN is a special number which is not a number =
(and which *would* probably pass a float type annotation, no?). FALSE isn't=
 a special integer which isn't an integer -- it is already something else, =
it's a boolean. JS has a few special values which are specifically designat=
ed as different failures or lack-of-values -- undefined, null, NaN, etc. PH=
P's FALSE does *not* fall into that category -- it *does* mean something, i=
t means something else, the boolean value false. (FWIW, I don't think that =
the way JS does this feels quite right either, I don't like that there are =
multiple sorts of non-exception failure values, but at least they return a =
designated failure value that doesn't have another totally different non-er=
ror meaning.)

Josh Watzman