On Sun, Apr 28, 2019 at 7:45 PM Stanislav Malyshev <smalys...@gmail.com> wrote:
>
> 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.I wish we could stop having this conversation on this list over and over. A certain level of backwards compatibility is essential, but beyond that you limit the future by the mistakes of the past. In a language like PHP a lot of mistakes were made, which greatly limits the future. Every time I try to add a feature which ought not to break anything I discover some horror in our language. Fixing bugs are often just as bad. Now, back to this particular BC break: it doesn't really enable a lot of future things, so here I can understand the resistance. Personally, I am slightly in favor of it. It seems like the precedence of concatenation ought to be lower than most other operators, because it doesn't make sense to use those operators on the result of the concatenation. This has occasionally caused small bugs in our code, and would prefer to fix it long-term. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
