Normalizing Const Syntax.

[Georg Wrede]

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.  

Suppose one has a new language to learn, and the syntax would be 
inconsistent between, say, storage class, access qualifier, and type 
attribute. How is one supposed to learn the difference?

While those who are familiar with a language may not "see" this, it is a 
severe stumbling block for those who really try to understand things. 
Ahd that's the kind of programmers we want to D.

> 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
> 
> 
>