Hi! > 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.
Most cases where bool is used is meant as "yes or no" parameter. In those cases, getting non-boolean there may mean one of the following: 1. A complete error, passing wrong parameter by mistake. 2. Passing something that is meant to represent preference, but is not an actual boolean - i.e. null, empty string, string '1', object, etc. Traditionally, many languages - including PHP - were lenient in accepting non-boolean objects in boolean contexts - so you can say if($obj) and mean "true if $obj is a real object, false if $obj is something like false or null" instead of if((bool)$obj). In such context, it is clear what the intent is, and the possibility of error is very low. However, when passing parameters the other option - one that implies the error was passing a different parameter - is an option. The question is how potential catching such error - noting that it would be caught only if the other parameter is not boolean and the value is not boolean and we do not use (bool) - is important over other considerations. So here I would say we should take a consistent approach. By this I mean - if we say scalar typing is coercive - i.e. if you say foo(bar $x), it means $x should be coerced into type "bar" or rejected if it does not make sense - then we should follow the general rules of boolean conversion and say any object can be turned into boolean, by the same rules as if() would take them. If, on the contrary, we take it as $x must be of type bar, or we reject it - then we should not accept anything but boolean. This however will lead us into strict typing, the concept which I personally oppose in this context, but would not elaborate further here since it was already done many times. In any case, I think it is important to realize this decision is not arbitrary, but connected to the rest of things - if you choose strict, it makes no sense to be strict only in one place. If you choose coercive, type casting rules should be consistent for all cases, not special for every syntax. > 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. Making it strict would not help here - people would just be trained to write (bool) everywhere, and thus the same bugs would be masked the same way, only in much uglier code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
