On 14 July 2014 13:58, Andrea Faulds <a...@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 exception
> of objects, but we can’t really do anything about that), bool’s behaviour at
> the moment is quite different. I don’t think it makes sense so I won’t
> discuss the current behaviour, only possible new ones.
>
> One option is simply to forget about being lossless and make the bool type
> 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 stupid
> programmer (like myself ;) has passed in a non-boolean truthy/falsey value to
> your function, it’ll be handled correctly. It would mean all your bit hacks
> ($foo & FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1).
> However, this is unlikely to catch bugs in code, because literally any PHP
> value would work. For that reason, I’m not sure this is the way forward.
>
> Another option is go completely strict and allow only boolean values, failing
> 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’t very “PHP-like”, and forcing people to manually cast
> with (bool) might not be ideal. If we were to go for this one, I might also
> accept objects casting to bool (which the default handler does), because I
> don’t want to stop extension developers from making bool-like objects if they
> so please.
>
> The final option I’m thinking about is a limited set of values. TRUE, FALSE
> and NULL would be accepted, along with the integer and float values 1 and 0
> (which are the int/float TRUE and FALSE cast to, respectively), ‘1’ and the
> empty string (which are the string values TRUE and FALSE cast to), and ‘0’
> (which (string)(int)FALSE would give you), along with objects casting to
> boolean. It’s not a perfect solution, but I currently feel that this is the
> most sensible option bar going for full strictness.
>
> I’m not really decided, however. Every time I try to think about this, I
> usually end up going in circles. Anthony doesn’t seem to be decided either.
> Hence I’m 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 else:
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 != 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
