Re: REMATCH_PCRE with zsh built without pcre support

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Mon, Apr 03, 2017 at 11:00:16 -0700:
> On Apr 3, 11:26am, Daniel Shahaf wrote:
> }
> } I agree that semantics of operators shouldn't depend on option
> 
> I'm not even particularly worried about semantic dependency; the gripe
> here is that "setopt re_match_pcre" does not succeed (or fail) based on
> the presence (or absence) of the module.  Exactly how big a problem is
> that?  If you are relying on =~ having perl semantics, you ought to be
> calling "zmodload zsh/pcre" anyway, and not just expecting setopt to do
> that for you.

Yes, you should load zsh/pcre before using =~ with Perl semantics;
setopt won't do that for you.  No one is disputing either of these
assertions.  The question is just what should the failure mode be when
zsh/pcre _should_ have been loaded, but [due to a bug in the user's
script] hadn't been.  Should errflag be set once REMATCH_PCRE is set, or
at the first affected use of =~ ?

That's not a trivial question, but the point I was trying to make in my
previous post is that, while both of us might prefer [for different
reasons] that REMATCH_PCRE had never been added, we can't just remove it
tomorrow morning; before removing that option, we should provide an
upgrade path to users who use it correctly (= with 'zmodload -e' checks)
and rely on it to continue to work as documented.

That's all I was trying to say.  I'll step out of this thread for a day
or two now.  Apologies if I've tested your patience, that wasn't my
intention.

Cheers,

Daniel