Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78167
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>
CC: PHP Internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Safe Casting Functions
Thread-Index: AQHP7LlZiSKK4iJP+UuYlFeFZanGU5w6MpeA
Date: Tue, 21 Oct 2014 01:07:13 +0000
Message-ID: <9ADD6AAC-A402-44B6-B9AA-A3F5F8A225AD@fb.com>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me>
In-Reply-To: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <502CCF555D326440BF6689A921238CFB@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 3:57 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Good evening,
>=20
> I am presenting a new RFC to add a set of three functions to do validated=
 casts for scalar types:
>=20
> https://wiki.php.net/rfc/safe_cast
>=20
> Please read it.
>=20
> Thanks!

I think this is pretty cool, but I'm really worried about some of its typin=
g implications. In particular:

> The functions return FALSE on failure instead of NULL because:

Throwing an exception or even returning NULL seems so much better than retu=
rning "false" -- "false" is a boolean, not an error, and despite some histo=
rical cases of PHP using "false" as a poor person's error code, it really i=
sn't. If you want error codes, use error codes, or use exceptions, but havi=
ng two kinds of failure, null vs false, is really confusing.

Addressing your arguments one by one:

> 	=95 If strict type hinting were added, they would fail for a nullable ty=
pehint

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 t=
he return type of, for example, to_int is now "int | bool" as opposed to "n=
ullable-int" or "int" (if you throw).

> 	=95 FALSE is a traditional error value in PHP

Since this is a new function, one that doesn't interoperate in any complica=
ted way with the existing library or affect BC, this doesn't seem that impo=
rtant. IMO a language should have one failure/absense-of-value, in most cas=
es "null", and having a weird second case seems, well, weird. If you have m=
ore interesting failure cases, just throw an exception, or return null if y=
ou want, don't continue propagating a weird second kind of null (that isn't=
 actually null, it's a boolean false).

Also, that we *couldn't* introduce a meaningful to_bool function, even if w=
e decided we wanted it, indicates to me that returning false is the wrong t=
hing to do.

> 	=95 NULL is used to signify the absence of a value - but what we want to=
 signify is an invalid value (similar to 0 vs NaN)

I might argue that failure is indeed absense-of-value, but an exception see=
ms like a much better way to convey this.

It's also interesting to look at how other languages handle failures of thi=
s 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 o=
f ways, throws. Functional languages do more interesting things; Haskell do=
es something complicated but morally equivalent to returning null. But I'm =
not aware of any language which specifically returns false.=