[RFC] Change the precedence of the concatenation operator

> > Hi! > > > Nikita, impressive leg work; thanks. It validates Bob's intuition from the > > RFC ("... these occurrences are quite rare as it almost always is an error > > in the current form, rendering the impact minimal.") > > If the impact is minimal, why do it at all? So, at the cost of BC break > and breaking old code (which is most definitely not in composer packages > and likely isn't publicly accessible) we maybe fix 5 bugs. Does this > justify a BC break? I don't think so. I really wish we'd stop trying to > add a thousand small incompatibilities between PHP 7 and PHP 8.

> > > Nikita, impressive leg work; thanks. It validates Bob's intuition from > the > > RFC ("... these occurrences are quite rare as it almost always is an > error > > in the current form, rendering the impact minimal.") > > If the impact is minimal, why do it at all? So, at the cost of BC break > and breaking old code (which is most definitely not in composer packages > and likely isn't publicly accessible) we maybe fix 5 bugs. Does this > justify a BC break? I don't think so. I really wish we'd stop trying to > add a thousand small incompatibilities between PHP 7 and PHP 8. >

> On Mon, Apr 29, 2019 at 9:34 AM Zeev Suraski <zeev@php.net> wrote: > > > > > > > On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov <nikita.ppv@gmail.com> > > wrote: > > > >> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand <bobwei9@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/a4df3e8e18c795 > >> <https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa> > >> > >> Zeev > >> > >> 5c2c21cf6cdb4cbfaa > >> <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). > > > > Even if something is not published via packagist proper, it will commonly > be redistributed there. E.g. in the dataset I used, WordPress is > represented through the roots/wordpress package (a packagist mirror of > 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. > > > > Absolutely. This only looks at a very small fraction of PHP code, though > also at a very important fraction. We do need to be carefully about where > and how the methodology is applied, for example it would make very little > sense to use this approach to analyze short tags usage -- that's clearly > something that will be predominantly found in proprietary template code, > not inside open-source libraries that have no need for templates to begin > with. > > TBH my main concern with this change is not the BC impact, but the concept > of doing precedence changes at all. This is going to be a pain for 3rd > party tooling, e.g. I'll have to add an entirely separate parser for PHP 8 > to the PHP-Parser library.

>> 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).