Normalizing Const Syntax.

[Georg Wrede]

Bill Baxter wrote:
> Koroskin Denis wrote:
>> Bill Baxter wrote:
>>> Janice Caron wrote:
>>>
>>>> However, there is a reason why Walter has not made const-at-the-front
>>>> illegal, which is that /he likes it/. And so far as I can gather, the
>>>> reason that he likes it is because it means he is able to write
>>>>      const
>>>>     {
>>>>         /* lots of functions */
>>>>     }
>>>
>>> Which is a horrible syntax in my opinion.  Something to be avoided 
>>> rather than something to bend over backwards trying to support.  Why 
>>> should a big block-o-const only affect the 'this' arguments of 
>>> functions inside of it? 

That is a good point.

>>> Not to mention, the bigger the block-o-const, the more likely it 
>>> is that someone reading the code will not see the const label.
>>
>> The same could be said for private or static methods. Do you propose 
>> we should get rid of these, too?
>> IMO, it's a matter of style. You can but, you don't have to use that 
>> syntax.
> 
> Those are different because private or static does indeed apply to the 
> methods as a whole, and not just one particular parameter of the methods.
> 
> But anyway, I have started to loathe all the nonlocal ways to set 
> protection levels, because I'm forever looking up and down in the class 
> to try to figure out what's public and what's not.  I'm not going to say 
> we have to get rid of those, but there better be a really compelling 
> reason to add more.

Well, there are a lot of things where one can choose the wrong way of 
writing code. And I believe the

attribute
{
     definition;
     definition;
     ...
}

style is meant for a long bunch of one-line definitions.

Only an idiot would spread the attribute over several pages.

This of course means that if one has a class or simply a list of 
definitions, that starts to grow multi-line, there comes a point where 
the attribute envelope should be deleted and the definitions attributed 
individually. (A good text editor should do this, btw.)

Deciding up-front whether to use the envelope or individual attributions 
is like deciding up-front whether to use OO-only or procedural-only. Not 
very practical.