develooper Front page | perl.perl5.porters | Postings from February 2017

[perl #130497] Revert "Unescaped left brace in regex" fatality

Thread Previous | Thread Next
From:
Karl Williamson via RT
Date:
February 8, 2017 17:18
Subject:
[perl #130497] Revert "Unescaped left brace in regex" fatality
Message ID:
rt-4.0.24-4074-1486574293-707.130497-15-0@perl.org
On Mon, 06 Feb 2017 08:23:25 -0800, jkeenan wrote:
> On Fri, 20 Jan 2017 00:36:59 GMT, public@khwilliamson.com wrote:
> > On 01/17/2017 02:52 PM, Leon Timmermans wrote:
> > > On Tue, Jan 17, 2017 at 9:10 PM, Sawyer X <xsawyerx@gmail.com
> > > <mailto:xsawyerx@gmail.com>> wrote:
> > >
> > > On 01/16/2017 07:28 PM, Leon Timmermans wrote:
> > >     > On Sat, Jan 14, 2017 at 9:38 PM, Sawyer X <xsawyerx@gmail.com
> > >     > <mailto:xsawyerx@gmail.com>
> > >     > <mailto:xsawyerx@gmail.com <mailto:xsawyerx@gmail.com>>>
> > >     > wrote:
> > >     >
> > >     > Going back to the original discussion on the value of making
> > >     > this
> > >     > change
> > >     > this way vs. reverting and then doing it again: there is a
> > >     > considerable
> > >     > value in doing it now. Introducing iterative changes is
> > >     > easier
> > >     > (for
> > >     > users) than introducing one major breakage that includes many
> > >     > different
> > >     > changes.
> > >     >
> > >     >
> > >     > Can you concretize this for me? Preferably something like
> > >     > "doing this
> > >     > now enables us to do X in the next release, which would
> > >     > otherwise not
> > >     > be possible".
> > >
> > > I'm not sure this is the best way to phrase what I meant, but let
> > > me
> > > try
> > > using these terms:
> > >
> > > The regular expression syntax has been cleaning up over time. This
> > > allowed us to remove possible problems, clean up confusing syntax,
> > > tighten up the syntax, and even add features (/xx was just reused a
> > > few
> > > commits ago by khw). This specifically is a good example, because
> > > it
> > > shows khw's long-term plans, which he works out in piecemeal,
> > > making
> > > small changes each time, eventually create enough room to introduce
> > > something new.
> > >
> > > If we had done all the changes that would facilitate these new
> > > features
> > > or fixes in one pass, it would have broken a wider range of modules
> > > and
> > > programs in numerous ways. This would have taken longer to figure
> > > out,
> > > to provide pull requests and patches for, to convince authors to
> > > merge
> > > and release new versions, and could eventually lead to more
> > > frustration
> > > with authors who have written code that now broke in multiple ways.
> > >
> > > My point is that while this breakage *will* occur, there is an
> > > value
> > > in
> > > making only *this* one this time, instead of this *plus* another in
> > > the
> > > next version. That's not to say I'm strongly opposed to reverting
> > > this.
> > > Neither is Karl.
> > >
> > >
> > > I think you missed my point, you're giving a philosophical answer
> > > where
> > > I'm asking for a tangible result.
> > >
> > >     > Given the other left-braces warning I don't see how there is
> > >     > any X for
> > >     > the next two releases, making this hurry pointless to me.
> > >
> > > I'm sorry. I didn't understand this sentence.
> > >
> > >
> > > As far as I know, Karl (correct me if I'm wrong) can't execute his
> > > long-term braces plan (a tangible result) until the other warning
> > > becomes fatal too (after 5.30).
> > > Not fatalizing this warning now will not obstruct any future plans
> > > as
> > > far as I can tell, and will allow for a smoother upgrade path to
> > > 5.26
> > > (giving people more time to escape their braces).
> > >
> > > Leon
> >
> >
> > I'd have to spend some time figuring out what could be done with the
> > portion of the braces gone in 5.28.  As I recall, it wouldn't be a
> > lot.
> > That's why I haven't been too concerned about reverting.
> >
> > But since this is viewed as a bug fix, it doesn't have to be done in
> > time for the visible changes load, so we have more time to discuss
> > it.
> 
> Until Jan 31 CPANtesters was impeded from getting a full picture of
> the impact of this fatalization on the building and testing of CPAN
> distributions because one distribution with over 600 first-level
> reverse dependencies was failing for this reason in one test,
> preventing the full testing of that distribution and all distributions
> which depended upon it.
> 
> That situation has now been remedied.  (Kudos to Toby, Nigel, sawyer
> and many others for their attention to this situation.)  CPANtesters
> is therefore now in a much better position to assess the impact of
> this fatalization on CPAN as we head to 5.26.0.
> 
> Over the last week I used 'cpanm' to build and test that distribution
> (Type-Tiny) and all its reverse dependencies.  I am pleased to report
> that I discovered only one previously unreported instance of a CPAN
> distribution getting a FAIL due to this fatalization.  I filed a bug
> report for that ticket.  Slaven, Andreas, Karen E and others have
> already filed bug reports for all other CPAN distributions
> experiencing FAILs due to this fatalization.  (Details available upon
> request.)
> 
> Therefore IMO there is no significant barrier to the implementation of
> this fatalization in 5.26.0.  I would not be in favor of delaying this
> implementation until 5.28, though I acknowledge other people think
> otherwise.  But we have IMO taken every step we practically can to
> warn users of potential problems.
> 
> Hence, I recommend that we *not* perform the reversion cited in the
> subject of this ticket.
> 
> Thank you very much.
> Jim Keenan

It occurs to me another argument in favor of keeping it fatal is, as I've said before, I think it is safer when making a change that can cause working programs to have a different behavior, to have that syntax to be fatal for a release or two.  That's why I originally was going to have /xx be fatal for 5.26.  But the fact that it was fatal during essentially the entirety of the 5.25 series without a single BBC report convinced me it was ok to go ahead and change the meaning.

I think that by making this portion of the unescaped '{' fatal in 5.26, we will lessen the chances that the final portion will create problems in future releases.
-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=130497

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About