Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106265
MIME-Version: 1.0
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
 <5C8F3403-2972-467A-AFA5-347C09E5FA73@gmail.com>
In-Reply-To: <5C8F3403-2972-467A-AFA5-347C09E5FA73@gmail.com>
Date: Tue, 23 Jul 2019 23:03:05 +0200
Message-ID: <CAF+90c-oN=_rjFyq4HbMCwyq=xhDopnF5ETy_oViL_DbjD=2oQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ce6877058e5f85fe"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ce6877058e5f85fe
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 23 July 2019 18:54:48 BST, "G. P. B." <george.banyard@gmail.com> wrote:
> >The only point of contention of this RFC that I potentially see is the
> >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
> >instead of it being removed in PHP 9 after it having had a whole major
> >version release cycle.
>
> Given that you've already predicted that this will be controversial, could
> you provide some rationale for it? Unless there's a major burden in
> maintaining the parser error behaviour for a few years, waiting for the
> next major version would seem both safer and more in line with official
> versioning policy.
>
> As with deprecation itself, any violation of the "no breaking changes"
> rule, however slight, should have an explicit justification. If I had a
> vote, any RFC omitting such a justification would receive an automatic "no"
> from me.
>

I agree. I don't think there's a pressing need to do the "full removal" in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

Nikita

--000000000000ce6877058e5f85fe--