On 15 Jul 2014, at 15:28, Rowan Collins <rowan.coll...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
