Re: Trimming strings, /emacs/lisp/emacs-lisp/subr-x.el modification

[Yuri Khan]

On Sun, May 7, 2017 at 11:53 PM, Eli Zaretskii <address@hidden> wrote:
>> >> >> I think regexp should be surrounded by a grouping construct, like:
>> >> >>
>> >> >>    (concat "\\`\\(?:" (or  regexp "[ \t\n\r]+") "\\)")
>
> I'm _asking_ whether it should be the caller's duty.

The issue is not unique to regular expressions. It is a poster example
for C preprocessor macros.

    #define TWICE(x) 2 * x

vs

    #define TWICE(x) (2 * (x))

The top example places the duty of correctly parenthesizing the macro
argument and the whole invocation on the caller. The bottom example
assumes that duty itself.

Pretty much every coding style guide resolves the issue in favor of
the latter. Meyers’ razor: [Make interfaces easy to use correctly and
hard to use incorrectly.][1]

(Also, pretty much every C++ coding style guide says “avoid
preprocessor macros; use language constructs that actually care for
syntax, such as functions and function templates”. In Elisp, the
closest although imperfect analogy would probably be (rx-to-string `(:
string-start (regexp ,regexp))), which does add a non-capturing group
where needed.)

[1]: http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_revised.htm


Now, the issue at hand is: Do we want to expose all the broken code
that is using the existing interface incorrectly, or do we keep
backward bug compatibility?