On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov [email protected]
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:
Similarly to the ternary associativity RFC, I've analyzed the top 2000
composer packages and checked whether they would be affected by this
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.
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
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
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.