On 16 Jul 2014, at 10:29, Zeev Suraski <z...@zend.com> wrote: > For me the introduction of a new set of rules is a deal breaker. > I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as > implicit casts, plus change implicit casts to emit E_CAST in case of loss > of data or 'bogus' conversions. > > Why insist E_RECOVERABLE_ERROR and introduce this effectively new set of > rules, instead of switching to E_CAST and maintain consistency? > Maintaining consistency is a HUGE deal. Every such feature we add that > you need to learn more rules/exceptions for make PHP harder to learn.
As has been pointed out already, that would be inconsistent with existing type hints. zend_parse_parameters emits E_WARNING and returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make scalar type hints not emit E_RECOVERABLE_ERROR and instead do something weaker would introduce *more* inconsistency, not less. Also, again, while these new rules aren’t quite the same as zpp’s, they are largely the same, and these rules are able to be summed up clearly in a single sentence, unlike the confusing and inconsistent zpp rules. We could fix zpp later, but that would be harder as it would break backwards-compatibility. And again, these new rules only different from zpp in very few places (integral values, “123abc” and booleans). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
