bug#55676: [PATCH] non-recursive Lisp reader

[Po Lu]

Mattias Engdegård <mattiase@acm.org> writes:

> No, that's not a cast.

It visually is one.  We never write code that looks like this:

  (int *)foo

instead writing

  (int *) foo

so I don't see why

  (struct foo){ ...

has to differ.

> Existing usage seems to vary; I don't see either as strictly more
> readable than the other.

I don't often see compound literals used as arguments to functions in
Emacs code, but certainly never where there is no space between the
parenthesized type name and initializer list.

Searching for "){" only reveals code that you installed.  Meanwhile, in
lisp.h, there is:

#define list(...) \
  listn (ARRAYELTS (((Lisp_Object []) {__VA_ARGS__})), __VA_ARGS__)
#define pure_list(...) \
  pure_listn (ARRAYELTS (((Lisp_Object []) {__VA_ARGS__})), __VA_ARGS__)

in xfont.c:

            char2b[i] = (XChar2b) { .byte1 = code[i] >> 8,
                                    .byte2 = code[i] & 0xFF };

and in fns.c:

Lisp_Object
concat2 (Lisp_Object s1, Lisp_Object s2)
{
  return concat_strings (2, ((Lisp_Object []) {s1, s2}));
}

Lisp_Object
concat3 (Lisp_Object s1, Lisp_Object s2, Lisp_Object s3)
{
  return concat_strings (3, ((Lisp_Object []) {s1, s2, s3}));
}

where there is a space between the type name and initializer list.

Changing instances of the wrong coding style that are already installed
would mess up the VCS history, but new code should comply with our prior
precedent, since applying coding style inconsistently leads to code that
is difficult to read.