Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <53C53A96.2040303@gmail.com>
Date: Tue, 15 Jul 2014 15:49:28 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <F7325DBA-BD31-4548-803D-D78B514BCB20@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 15 Jul 2014, at 15:28, Rowan Collins <rowan.collins@gmail.com> wrote:

> Stas Malyshev wrote (on 14/07/2014):
>> But I'm not sure why you need this. You accept that if("foo")
>> works. Then why "function foo(bool $x) { if($x) { ... " should work
>> differently?
>=20
> The answer - which is definitely a matter of opinion - is that =
allowing any string reduces the usefulness of the type hint.
>=20
> I realise there is not consensus on whether scalar hints should =
represent validation, cast, or a mixture, but *if* we go down the route =
of validation, then we have to choose which values are valid and which =
are not.
>=20
> My preference is to keep that strict: the example others have posted =
of some_func($foo & BIT_FLAG) seems no more like a "real" boolean to me =
than some_func(strlen($foo)) or any other expression which yields an =
integer.
>=20
> In fact, I'd find the behaviour more obvious if it were written =
some_func((bool)$foo & BIT_FLAG) - it makes clear that some_func is not =
itself aware of the flag, that's just the caller's way of making the =
decision. That the type hint encouraged that would therefore seem like a =
Good Thing.
>=20
> (I'd post that comment on the appropriate sub-thread where that =
example was raised, but don't have time to find it=85)

Right. For the sake of consistency with the other scalar type hints, I=92m=
 current leaning to what I=92ve made the RFC do, i.e. be completely =
strict for booleans. This is because we have string, float and int only =
allow losslessly convertible, equivalent values. Unfortunately, I=92d =
argue there aren=92t really such things for booleans except for true and =
false. Furthermore, forcing people to cast here isn=92t such a bad =
thing; a cast to bool will always be somewhat lossy, and while =
explicitly casting to int or float might be dangerous, I can=92t think =
of any place where it=92s actually a bad idea to explicitly cast to =
bool.

--
Andrea Faulds
http://ajf.me/