Subject: A minor syntax request

From: Daniel van Vugt <[email-masked]>
Date: Tue, 16 Apr 2013 18:06:15 +0800

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;

Do we really need to be so strict about using the Mir convention:

     T const x
     T cons& x
     T* x

?

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 16 Apr 2013 11:32:55 +0100

On 16/04/13 11:06, Daniel van Vugt wrote:
> 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;

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:

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.

---

From: Petko <[email-masked]>
Date: Tue, 16 Apr 2013 13:50:06 +0300

On 04/16/2013 01:32 PM, Alan Griffiths wrote:
> 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. 
I'm subscribed  mainly as a spectator , but I have to note that the 
tradition is less important than the program logic (in most cases , 
since we shouldn't keep the mistakes of the people before us till the 
end of time) . If the C/C++ standard says that the */& belong to the 
variable , then they should be visually associated with it .

Petko

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 16 Apr 2013 11:55:43 +0100

> variable , then they should be visually associated with it .
The tradition is based on the reasonable belief that "*/&" is
semantically part of the type. Sadly, it is too late to fix the syntax
to agree with the semantics.

---

From: Petko <[email-masked]>
Date: Tue, 16 Apr 2013 20:57:47 +0300

> to agree with the semantics.
As I think about it , there is reason to accept */& as part of the type 
. It's apparently a question of perception . I tend to declare variables 
in batch , where appropriate (int x,y,z,*t ,*w //dimentions of A) and 
therefore associate the */& with the variable names in said syntax . So 
yeah , sorry for intervening , it's apparently the code maintainers 
decision , not so much an arguable point .

Best regards ,
Petko

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 17 Apr 2013 09:28:28 +0800

Actually I was not requesting "/3/ Allowing multiple variables to be 
defined in a declaration". Just using it as an example. Although I would 
like to be able to do so, use cases for it are less common so am happy 
to say one variable per declaration if that is the style.

And I totally agree that */& being part of the variable was a poor 
language design decision. But that was probably 40 years ago. It's 
established and that's the way it works.

Back on the const'ness issue... Another reason for const prefixing is 
this case:
     const T * const x = y;
If you don't prefix const then it is significantly more confusing:
     T const * const x = y;

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 17 Apr 2013 09:35:21 +0100

On 16/04/13 18:57, Petko wrote:
> sorry for intervening

Don't be