Normalizing Const Syntax.

[Bill Baxter]

Janice Caron wrote:
> I think it would be enormously wrong for
> 
>     const int x;
> 
> and
> 
>     const(int) x;
> 
> to mean two entirely different things (which I think was part of what
> Scott was suggesting). But I do agree with all the rest of it.
> 
> So here's something to think about. Consider the following code:
> 
>     class C
>     {
>         const
>         {
>             T x;
>             T f() { ... }
>         }
>     }
> 
> What would be the most intuitive meaning of f's const. Would it be:
> (a) the function expects "this" to be const
> (b) the function returns a const(T)
> (c) both of the above simultaneously
> (d) none of the above
> 
> I think (b).

You could be right.  But either way, I object to the heavy use of 
non-local attribute modifiers that change the meaning of statements far 
from where they are written.  So even though it might be "cute" to put 
'static' or 'const' in a big block around a big chunk of functions,  I 
think doing such things is bad style.  I'm not a big Java fan, but I 
think maybe Java might have had it right on this one.  When I look at a 
big class in D I'm forever trying to figure out whether some unlabeled 
method is public/private/protected.  And several times I've been bitten 
by not noticing an innocuous little  "extern(C):" stuck at the top of a 
file.

> In D2.012, the actual meaning is (a), but pretty much everyone agrees
> that's not intuitive.

Indeed.  I also don't like the idea that lots of extra parenthesis will 
be forced upon us just to allow something which I think is of dubious 
value to begin with.  I.e., this should return a const value, not have a 
const 'this':
     const Bar Foo()
But with the current regime that has to get some extra parens to express 
that.  Too many parens in a signature makes it hard to read, so I really 
don't want "const(Bar) Foo()" to be the norm.

--bb