A minor syntax request

Alan Griffiths alan.griffiths at canonical.com
Tue Apr 16 10:32:55 UTC 2013


On 16/04/13 11:06, Daniel van Vugt wrote:
> Can we please start to allow the style:
>
>     const T x
>     const T &x
>     T *x
>
> I believe it is probably the most common syntax in general industry
> use, and also one that many of us are used to and most comfortable
> with. Other arguments for this syntax are:
>
>   1. It's part of the C/C++ language definition that &/* belongs to
> the variable and not the type...
>        T x, *y = &x;
>   2. It feels more natural for many readers to think "constant T" when
> reading "const T", than when reading "T const".
>   3. It's more obvious that your variable is a variable if you say:
>        const T *a;
>        a = b;
>      However writing it this way, it's less obvious that a is not
> constant itself:
>        T const* a;
>        a = b;

C/C++ declaration syntax is famously "an experiment that failed", but
using the well known "right to left" heuristic gives:

"a is a pointer to constant T" vs "a is a pointer to T constant"

>
> Do we really need to be so strict about using the Mir convention:
>
>     T const x
>     T cons& x
>     T* x
>
> ?
>

There are thee related requests hidden here.

/1/ Putting cv-qualifiers to the left of the type in the few (but
common) cases it is allowed syntactically.

Most cases have to be to the right anyway, so I've a mild preference to
"on the right" for consistency, and a strong preference for using what
the rest of the code does.

/2/ Putting * or & with the name, not the type.
/3/ Allowing multiple variables to be defined in a declaration

Putting * or & with the type has a long standing tradition within the
C++ culture - it started with the first edition of "The C++ Programming
Language" and has been common practice ever since.

There is an associated tradition of declaring each variable separately.
(These two go together as "pretending" the type includes * or & doesn't
work if multiple variables are declared.)

This is very different to the C tradition.




More information about the Mir-devel mailing list