On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand <bobw...@hotmail.com> wrote: > > > Hey, > > > > I feel like concatenation having the same precedence than addition and > > subtraction is promoting programmers to make mistakes. Albeit typically > > easy to catch ones, it is a quality of life change at least. > > > > Hence I'm proposing a RFC changing the precedences: > > https://wiki.php.net/rfc/concatenation_precedence > > > > Bob > > > > Similarly to the ternary associativity RFC, I've analyzed the top 2000 > composer packages and checked whether they would be affected by this > change: https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa > > The tl;dr is that there were 5 instances where behavior would change per > this RFC, and all 5 of them are bugs in current code and would be > interpreted correctly after this RFC. Nikita, I'm a bit worried that using this as a standard test suite may (repeatedly?) give us a false sense of security to go ahead with compatibility breaking changes. Composer packages, almost by definition - tend to be of higher quality than the 'average' PHP code (at the very least they're redistributable, but arguably Composer users are more advanced than the average developer - even more so those who publish packages). On top of that - probably the some of the most redistributed pieces of code in the PHP space - aren't covered by Composer at all (e.g. WordPress). Don't get me wrong - I think it's great to have this indicator, but unless I'm missing something, it's far from being something we can thoroughly rely on to determine whether a certain feature is commonly used or not. A huge chunk of the PHP codebase is completely invisible to us, and much of the code that is visible to us does not reside inside Composer. Zeev
