On 16 Jul 2014, at 13:28, Zeev Suraski <z...@zend.com> wrote: > It's more of a lossy cast, exactly as we have today, that has an > (effectively-optional-since-it's-off-by-default) to warn you about loss of > data. > For the vast majority of users who use the defaults, there'll be nothing new > to learn except for the availability of those implicit casts in function > signatures. > For those who want to take advantage of 'loss protection', they'd have to > learn about this extra warning type and clean their code so that it adheres > to it. But there too, they'd have consistency, just one set of rules for > implicit cast of scalar values across all of PHP.
The problem with making this RFC do the lossy thing is it then removes one key advantage of it: that this RFC provides a measure of strictness. Without that, we have no real compromise proposal, and we might as well introduce a second set of “strict” type hints. The whole point of the current behaviour is that it compromises between the weak typing and strict typing camps; doing what zpp does is giving in to the former camp, and then it’s not a compromise any more, is it? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
