Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105582
MIME-Version: 1.0
References: <VI1PR08MB2799B05BFB2CD3FB42E6222AE23A0@VI1PR08MB2799.eurprd08.prod.outlook.com>
 <CANUQDChnDaMudh9uaKcjD+jFA7U1LO6m_x2PRa7ujzA88_RegQ@mail.gmail.com>
In-Reply-To: <CANUQDChnDaMudh9uaKcjD+jFA7U1LO6m_x2PRa7ujzA88_RegQ@mail.gmail.com>
Date: Fri, 3 May 2019 18:50:51 +0200
Message-ID: <CAAfnsFUdj0yk9J2+Jeid7077aSVkF4qhXZ52Hy75Usw7TTqgSA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [Vote] Change the precedence of the concatenation operator
From: peterkokot@gmail.com (Peter Kokot)

Hello,

On Fri, 3 May 2019 at 16:19, Niklas Keller <me@kelunik.com> wrote:
>
> Hey Bob,
>
> in the RFC you mention:
>
> > While this is a subtle behavior change in that it will give different outputs without notice or warning, it is trivially possible to statically analyze the code and find all instances where this happens.
>
> On the other hand, there's:
>
> > PHP 8, with a deprecation notice in PHP 7.4 upon encountering an unparenthesized expression containing an '.' before a '+' or '-'.
>
> So there will be a notice if the second vote passes and the output
> changes in PHP 7.4.
>
> Regards, Niklas
>
> Am Mi., 1. Mai 2019 um 00:41 Uhr schrieb Bob Weinand <bobwei9@hotmail.com>:
> >
> > Hey,
> > As announced yesterday, I'm now starting the vote on this RFC.
> >
> > I'm confident that the impact is really that minimal that a relatively quick deprecation and change path is preferred.
> >
> > https://wiki.php.net/rfc/concatenation_precedence
> >
> > The vote ends on May 15.
> >
> > Thanks,
> > Bob

Thank you for the RFC. Apologies for not responding here sooner. I
just want to point out one thingy here also (that is becoming sort of
a pattern recently and also because this has been pointed out at
another RFC that is causing issues with some people, yet no issues
here).

The removal of some feature (which causes a BC break) in PHP 8.0
should always emit a deprecated warning if that is possible to do on
given time in the code or to detect this feature. We could say that
situation is completely similar to the removal of the short opening
tags. If there is something to be removed or changed with BC break
effect in major release, the deprecation warning is self-evident and
therefore I'm not sure why the additional vote here. Because again, an
edge case scenario we could get a changed functionality in PHP 8 and
no warning in PHP 7.4.

Just as an example and a bit of an additional info how the upgrades
from minor to major releases can go smoother.

Other than that, all looking good and thank you for your work.

-- 
Peter Kokot