Re: Reviving scalar type hints

hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov <dmitry@zend.com> wrote: > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara <ircmaxell@gmail.com> > wrote: > >> Larry, >> >> > Anthony, can you expand here at all about the practical benefits of >> > strong-typing for variable passing for the compiler? That seems to be >> the >> > main point of contention: Whether or not there are real, practical >> benefits >> > to be had in the compiler of knowing that a call will be in "strict >> mode". >> > (If there are, then the split-mode makes sense If there are not, then >> > there's little benefit to it.) >> >> For the normal compiler & engine there will be no benefit for the >> foreseeable future. >> >> For a tracing JIT compiler, there will be no advantage. >> >> For a local JIT compiler, there can be some optimizations around >> reduced conversion logic generated (and hence potentially better cache >> efficiency, etc). A guard would still be generated, but that's a >> single branch rather than the full cast logic. This would likely be a >> small gain (likely less than 1%, possibly significantly less). >> >> For a AOT compiler (optimizing compiler), more optimizations and >> therefore gains can be had. The big difference here is that type >> assertions can be done at compile time. > > > AOT compiler that know type of passed argument and expected parameter type, > may eliminate guard check independently on hint semantic (strong or week). > If you don't know first or second you'll have to generate guard code anyway > independently from hint semantic (strong or week). Is this wrong? > > We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. I think we can agree on that, and we did as far as I can tell :) > >> However, I think making this decision based on performance is the >> incorrect way of doing it. For the Zend engine, there will be no >> discernible difference between the proposals. It's a red herring. The >> difference I would focus on is the ability to statically analyze the >> code (with the benefits that comes with). >> > > Completely agree, changing language for compiler is not fair. > It's clear that statically typed languages are more suitable but we won't > make PHP statically typed. > Also, modern JS engines showed - what they may do without typing. Let put things correctly please: > In my opinion strict type hints may be useful for program verification, but > again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. > just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. Cheers, -- Pierre @pierrejoye | http://www.libgd.org