Normalizing Const Syntax.

[Scott S. McCoy]

I liked that about D actually, the attrition of syntax from other
languages provides flexibility regardless of your personal preference.

Some people like to type it out explicitly, so two pages of private
methods later they don't forget what they were looking at (or after
leaving and coming back to the computer, for instance).

Alot of these people (although, not all of them I'm afraid) *also*
segment their public and private members, although not with the local
syntax, but just at some point in the file.

Maintaining largely compatible syntax and hence concepts across
languages like Java, C# and Ferite, means that D is easy to adopt.  And
the same is true for maintaining the C++-ish syntax, of having public:
local labels.

I think the problem with const is just what we've identified earlier in
the thread, the keyword for "this method doesn't change anything" should
just probably not be the same keyword as "this is a read only reference,
and so are it's descendants".

Additionally, I'd like to defend the rationale behind my original
proposal.  I was following this, apparently already existing definition
of a type annotation:

annotation(type);

Which means:

const(int), makes "const" an annotation, or attribute if you will, of
the type.

Really, type attributes or annotations should have some completely
different syntax, if you ask me.  Because this existing syntax makes
"const" more like a special function, similar to "cast()" which is
already kind of mind-boggling.  Something along the lines of a marker
which asthetically provides an extension of that type.

int : const foo = blah.

public const int:const foo (int:const bar); 

might be adequate, although it's asthetically quite similar to janice's
previous suggestion of saying that the const must come after the type,
it has slightly different and more consistent semantics.  It implies
that a type could be defined as:

<type> ::= <type-keyword> |
           <type-keyword> <annotation-marker> <annotation-keyword>
<annotation-marker> ::= ":"
<annotation-keyword> ::= "const" | "invariant" ;; More to be defined,
possibly.

And this undoes the schizophrenia of how to refer to const, since now
"const" is perfectly safe as an access qualifier.

<access-qualifier> ::= "public" | "private" | "package" | "protected" | 
<static>           ::= "static"
<reference-access> ::= "const" | "invariant"
<access-level>     ::= <access-qualifier> |
                       <access-qualifier> <access-level>

<method-access>    ::= <access-level> <reference-access> <type> |
                       <access-level> <static> <type> |
                       <access-level> <type>

This syntax, whilst it may diverge from what currently exists in D,
introduces the divergent syntax in a divergent fashion which makes the
divergent concept of the redefined const suddenly more consistent, in my
humble opinion.

Again, I'm all for backward compatability, so this would mean that, you
could again re-introduce a more backwardly-compatible const, or
outwardly disable it, by making the following syntax "legal" or
"illegal" respectively and retaining or completely removing the previous
const definition.

private const int : const foo;

Although it's awkwardly redundant if retained, atleast it enables easier
D1->D2 porting, and if lost instead of retained, it provides a clearer
migration path for those who were previously relying on the older
definition of const and really should just remove it for D2.  Rather
than hiding the new behavior behind the older definition.

Cheers,
	Scott S. McCoy

On Fri, 2008-04-11 at 00:09 +0900, Bill Baxter wrote:
> Koroskin Denis wrote:
> > On Thu, 10 Apr 2008 17:53:56 +0400, Bill Baxter 
> > <dnewsgroup at billbaxter.com> 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?  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.
> >>
> >> It's a bad idea in my opinion.
> >>
> >>
> >> --bb
> >>
> > 
> > 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.
> 
> --bb