Re: Coercive Scalar Type Hints RFC

On Wed, Feb 25, 2015 at 7:32 PM, François Laupretre <francois@php.net> wrote: > About #1: if, one day, a majority decides that we absolutely need strict types, it will be very > easy. Just define four additional type hints, something like 'int!', 'float!', > 'string!' 'bool!' or any other syntax. These types would be defined as accepting > only their native zval type and, of course, performing no conversion. And that's it. Nothing > more. You have your strict types, function by function, argument by argument, return type too if you > want. Isn't it nice ? We decided not to propose such types because we think it would bring more > bad than good. That's just an opinion. Do you see the difference ? we don't propose strict > types for 7.0 but, if you gather a majority favoring it, they may be present in 7.1. I do not think this will even happen, not even in a distant future. > About #2: The risk is not so terrible. As the default is to turn off E_DEPRECATED messages in > production, it is even very low. The highest risk we take is to see a small performance hit. > Probably negligible compared to the phpng positive impact on performance. As I said earlier, E_DEPRECATED will only caught what it sees, we miss what it does not and actually casts happily. There is no performance hit, let get over that, we have published numbers to show that already. > And temporary because developers will quietly fix their code and the hidden messages will > disappear. So, we probably won't have to rely on 'good luck'. Again. It seems you only see issues with this insignificant E_DEPRECATED messages, it will be just like other or E_NOTICE, they will disable it and move on. However my point is in a totally different area, the one we have no idea what is going on because it is now casted while it was not before. We do not have data to cover these cases. It is not a lack of will but it is simply impossible to have for all apps out there in production (as you said before). And it is exactly why I am against changing the casting rules, even for a single yota beyond what we have done already (or close to this area). > FUD apart, every test Dmitry ran using his upcoming patch (which will implement E_DEPRECATED) > on existing PHP software raised very few new errors. More : after analysis, all these messages > except 1, I believe, correspond to undetected bugs in the PHP code. Like the bug I detected in the > PHP code to build phar.phar. So, I can go further : we are not breaking anything *and* we are > helping users to find undetected bugs in their codebase. Nice side effect, isn't it ? Again, see my previous comment in this mail. Cheers, -- Pierre @pierrejoye | http://www.libgd.org