[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Yuri Khan
Subject: Re: Trimming strings, /emacs/lisp/emacs-lisp/subr-x.el modification
Date: Wed, 10 May 2017 16:21:57 +0700

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


    #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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]