in reply to Re: non-capture mode sometimes erases previous capture
in thread non-capture mode sometimes erases previous capture
Thank you all for the responses. I'm convinced this is working as designed, not entirely convinced that the design is ideal, and fully convinced that the design won't change at this stage.
In addition to the sentence in perlre that haukex quotes, that document also says, "Capture group contents are ... available to you outside the pattern until the end of the enclosing block or until the next successful match, whichever comes first." Lesson: read documentation more thoroughly before posting.
It would be nice for s/// to have an option that means "don't capture and don't alter the existing values of $1, $2, etc." And it wouldn't break much in terms of back-compatibility if /n were this option: with the current behavior being to undefine all these variables when /n is used, extant code can't be relying on them for anything after a /n substitution. (I suppose some code might rely on them being undefined, but that seems a rare edge case.) Still, at the end of the day, if it ain't broke, don't fix it. There are other ways to save $1, so this hypothetical option might be an occasional convenience but certainly isn't a necessity.
I would still strongly recommend against using them for more than a couple of lines after the regexCompletely agree. I encountered this issue when using the variable in the target of the substitution, in an eval that ran another simple substitution. So it wasn't really any lines after the regex that populated $1.