On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn <petercowb...@gmail.com> wrote:
> > > On Tue, 23 Jul 2019 at 22:03, Nikita Popov <nikita....@gmail.com> wrote: > >> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins <rowan.coll...@gmail.com> >> wrote: >> >> > On 23 July 2019 18:54:48 BST, "G. P. B." <george.bany...@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 >> > > Would you (George, Nikita) consider removing the details about the > eventual removal of the feature from this RFC? We can run with the error > for a bunch of releases / years, and see what happens. I don't see why we > should necessarily decide now on something that might be 5 years or more > away. > I don't see a benefit in leaving this open-ended and prefer to have a fixed timeline for this. The full removal in 9.0 is already very, very conservative. Using short tags will have produced a fatal error for a whole major version at that point. If necessary the question can be reevaluated at that time, but the burden of proof must be on the people arguing an additional delay, not the other way around. Nikita
