Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75457
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
	<16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
Date: Mon, 14 Jul 2014 14:33:04 +0100
Message-ID: <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: daverandom@php.net (Chris Wright)

On 14 July 2014 13:58, Andrea Faulds <ajf@ajf.me> wrote:
> Hello again,
>
> One of the issues with the RFC as it stands is how to handle bool casting=
. While int, float and string only allow lossless casting (with the excepti=
on of objects, but we can=E2=80=99t really do anything about that), bool=E2=
=80=99s behaviour at the moment is quite different. I don=E2=80=99t think i=
t makes sense so I won=E2=80=99t discuss the current behaviour, only possib=
le new ones.
>
> One option is simply to forget about being lossless and make the bool typ=
e hint accept any value, meaning any truthy value or any falsey value would=
 yield what is expected without error. This would ensure that if some stupi=
d programmer (like myself ;) has passed in a non-boolean truthy/falsey valu=
e to your function, it=E2=80=99ll be handled correctly. It would mean all y=
our bit hacks ($foo & FLAG etc.) would work, anything you got from $_GET (e=
.g. ?foobar=3D1). However, this is unlikely to catch bugs in code, because =
literally any PHP value would work. For that reason, I=E2=80=99m not sure t=
his is the way forward.
>
> Another option is go completely strict and allow only boolean values, fai=
ling everything else. This would be unlike the int, float and string hints,=
 which are flexible and cast, but would be more helpful for catching bugs. =
However, not casting at all isn=E2=80=99t very =E2=80=9CPHP-like=E2=80=9D, =
and forcing people to manually cast with (bool) might not be ideal. If we w=
ere to go for this one, I might also accept objects casting to bool (which =
the default handler does), because I don=E2=80=99t want to stop extension d=
evelopers from making bool-like objects if they so please.
>
> The final option I=E2=80=99m thinking about is a limited set of values. T=
RUE, FALSE and NULL would be accepted, along with the integer and float val=
ues 1 and 0 (which are the int/float TRUE and FALSE cast to, respectively),=
 =E2=80=981=E2=80=99 and the empty string (which are the string values TRUE=
 and FALSE cast to), and =E2=80=980=E2=80=99 (which (string)(int)FALSE woul=
d give you), along with objects casting to boolean. It=E2=80=99s not a perf=
ect solution, but I currently feel that this is the most sensible option ba=
r going for full strictness.
>
> I=E2=80=99m not really decided, however. Every time I try to think about =
this, I usually end up going in circles. Anthony doesn=E2=80=99t seem to be=
 decided either. Hence I=E2=80=99m putting this up for discussion.
>
> What are your thoughts?
>
> --
> Andrea Faulds
> http://ajf.me/

I've already said this in IRC but summing up for the benefit of everyone el=
se:

1) We already have a place where there is an implicit boolean cast,
namely if ($var). Personally I would find it somewhat
counter-intuitive if a parameter declared as bool didn't behave the
same way.

2) A common-ish use case here would be:

   function foo(bool $bool) {}
   foo($flags & A_FLAG);

The intent of the expression $flags & A_FLAG is obvious to the reader
as fetching a boolean, but the result will often be an integer that is
neither 1 nor 0. This cannot be handled by foo((bool)$flags & A_FLAG);
because of precedence, foo((bool)($flags & A_FLAG)); is messy. Andrea
suggested foo($flags & A_FLAG !=3D 0); which is better but still a
little messy.

Personally I would rather just accept data loss and stay consistent
with the rest of the language (i.e. condition evaluation), but I do
understand the PoV of those resistant to it.