Re: A function to take the regexp-matched subsring directly

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> `save-match-data` is costly and extremely rarely needed.
>
> I committed a change that now makes inhibit-modify optional (though `(declare
> (pure t) (side-effect-free t))` is lost in the process).

Optional makes no sense: those who need the match data to be saved can
use `save-match-data` around the call just as easily as passing an
optional argument.

> Although I think intuitively, when running those kind of functions, we
> naturally expect them not to cause any side-effects from a high-level
> perspective so `save-match-data` should be the default.

That's not how it works: your intuition should say "oh, it uses
a regexp, so it most assuredly messes with the match data".  Only very
few primitive operations like `car/cdr` preserve the match data.
Everything else should be presumed to mess with the match data.
`save-match-data` should almost never be used at the top-level of
a function.
It should only be used in cases such as:

      ...
      (string-match ..)
      ...
      (save-match-data
        ...do something that may mess with the match data...)
      ...
      (match-string ..)

I tried to explain that in the docstring as follow:

    NOTE: The convention in Elisp is that any function, except for a few
    exceptions like car/assoc/+/goto-char, can clobber the match data,
    so `save-match-data' should normally be used to save *your* match data
    rather than your caller's match data."


-- Stefan