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?
>
> The answer - which is definitely a matter of opinion - is that allowing any string reduces the
> usefulness of the type hint.
>
> 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.
>
> 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.
>
> 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.
>
> (I'd post that comment on the appropriate sub-thread where that example was raised, but
> don't have time to find it…)
Right. For the sake of consistency with the other scalar type hints, I’m current leaning to what
I’ve 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’d argue there
aren’t really such things for booleans except for true and false. Furthermore, forcing people to
cast here isn’t 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’t think of any place where it’s
actually a bad idea to explicitly cast to bool.
--
Andrea Faulds
http://ajf.me/