Zeev, On Fri, Feb 13, 2015 at 6:34 AM, Zeev Suraski <z...@zend.com> wrote: > >> On 13 בפבר׳ 2015, at 13:13, Andrea Faulds <a...@ajf.me> wrote: >> >> Hi, >> >>> On 13 Feb 2015, at 09:37, Patrick ALLAERT <patrickalla...@php.net> wrote: >>> >>> Voted "no" because of the reasons already mentioned by a bunch of others >>> here. >>> >>> Weak type hint as presented earlier: +1 (and very good job Andrea about >>> that!). >>> declare(strict_types=1): -1, not only about the syntax, but also about the >>> mixed mode it introduces. >>> >>> I'm pretty confident that this RFC will "pass" with just above 2/3 of >>> majority while it could reach much more. >>> >>> I am pretty sure that if this RFC doesn't include a strict type mode _the >>> way it is proposed_ (or even, not at all, as part of another related RFC), >>> it would have some "no" converted to "yes" and would have a wider adoption, >>> which is for sure a better option than relying on a voting mechanism which >>> still is a supporting tool, we're not politicians after all :) >> >> It wouldn’t have wider adoption. Excluding a large portion of the PHP >> community (which favours strict types) and giving them something which >> doesn’t work for their use cases (weak types) is not going to win any fans. > > Any fans? Really? > > How about we put it to a test instead of guessing the outcome? >
We have long operated as a Do-ocracy in that the RFC author has final say over what goes into their proposal. You are definitely free to ask and make suggestions (and share opinions), but ultimately it's up to the author. Andrea, as the author of this RFC, has apparently decided that it isn't going to happen in this proposal at this time. Please respect that, even if you don't agree. With that said, there's nothing stopping you from putting up your time to create a competing proposal and patch. If you really believe that weak types are the better way forward, why not codify that? If only one of the RFCs passes, then you have your answer. If both pass, we can simply have another vote to choose which to move forward with. Competition is healthy for the community. You also said earlier in the thread that you don't agree with the points that I made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html). Can you share what you don't agree with (in the comments or this thread)? Rasmus posted some issues, most of which I consider details in this proposal (declare() and lack of handling the int->float conversion case) and I replied to them (I think they are handleable). If you have other disagreement, why not share? I would especially would like a response to the point that I made where I showed 3 examples where weak hints of any type would cause subtle and hard-to-find bugs; one of which was a high-level security risk. One final side-point: In my work on Recki-CT, I learned very early on that casts are quite expensive. When compiling mandel() from Zend/bench.php, the implicit casts that were happening on $w2, $x and a few other vars (which were ints) to floats for the computation added approximately 10% to the runtime of the function. The casts in mandel2 accounted for 20% of the runtime. Let me say that again: the int->float conversion in the loops accounted for between 10% and 20% of the function call. And that's not a dynamic cast (a branch based on type), it's a single `fild` instruction. Having the ability to statically know that a cast will never be needed can result in significantly faster (and easier) native code generation... Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
