On 14 Jul 2014, at 14:33, Chris Wright <daveran...@php.net> wrote:
> 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.
Yeah, that’s the problem for me. I want things like ($flags & A_FLAG) to work,
but I don’t want “foo” to work.
I suggested on IRC that empty strings, TRUE, FALSE, NULL, and values that
validate for the int type hint could be accepted. Is that a good idea? Though
it feels a bit loose, I think it covers all the important common use cases.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
