On 14 Jul 2014, at 13:58, Andrea Faulds <a...@ajf.me> wrote: > > 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.
> 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. I’ve made the patch and RFC do this, at least for the time being. I’m still not really decided, nor is Anthony. The main advantage of being completely strict is that it’s fully lossless; (bool)(string)$x === $x where $x was a boolean, but (string)(bool)$x !== $x where $x was a string. (Not necessarily, at least). This would make it an oddball among the scalars as it’s completely strict, and would require you to cast to bool explicitly in many cases… but at the moment it *seems* to be the most sensible option to me. Still, we’re both undecided. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
