Normalizing Const Syntax.

[Graham St Jack]

On Tue, 08 Apr 2008 15:51:22 -0700, Scott S. McCoy wrote:

> I've brought this up several times within threads, and not gotten any
> responses.  So I thought I would make it a thread of its own.  How about
> normalizing the syntax of const?
> 
> private const int foo;
> public const const(int) bar () { return foo; }
> 
> In the above example, the behavior of the keyword "const" is relatively
> schizophrenic.  const is listed as a part of the storage class for foo,
> and then as an access qualifier for bar(), with the same syntax.  While
> it should be noted that this type of behavior is suitable with static,
> but that is because the nature of static is different.  static is both a
> storage class and an access qualifier, and it behaves fine as such.
> 
> However the "transitive const" definition makes const no longer a
> storage class.  const is now an attribute of the value type, which is
> what makes it transitive.  Granted, this type attribute does change the
> behavior of storage, but that doesn't magically make its behavior
> consistent with storage-class keywords such as static, or extern.  It's
> a different class of concept.
> 
> It would seem more consistent with the essence of our new const
> definition if const was always an attribute of the type, when associated
> with an identifier.  So the syntax should reflect this, as per the
> following example.
> 
> private const(int) _foo;
> public const const(int) foo () { return _foo; }
> 
> This would also mean that:
> 
> private const int foo;
> 
> could retain it's previous definition, which is a part of what's making
> people so frustrated about const.  Since const is listed in the
> storage-class part of the declaration, const as a storage class could be
> possible.  Alternatively, const as a storage class could be a syntax
> error, if we really want to get rid of the concept entirely and not have
> two consts floating around.  This would make porting D1 code to D2
> easier, since it would either 1) Work as expected, or 2) Just not work
> and the compiler could tell you about it.
> 
> Cheers,
> 	Scott S. McCoy

I agree that the present syntax is a problem, but I'm not sure how your 
suggestion fixes the problem.

The two alternatives that make sense to me are:

const ReturnType const method_name();

const ReturnType method_name() const;

where in each case the first const applies to the return type and the 
second to the method.