Normalizing Const Syntax.

[Yigal Chripun]

Bill Baxter wrote:
> 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

the problem with the current syntax IMHO is that we want to specify
several different const meanings all at the same place in the code:
- constancy of the return type
- constancy of the this pointer (for methods)
- "constancy" of the code itself - i.e pure functions
to solve this we need to either,
a) have a different name for each of those (this is partly so with the
use of "pure")
// const_this & const_return are placeholders for 2 different keywords.
---> pure const_this const_return int func(int a, int b);
or b)  rearrange the syntax so each meaning has its own place.

in a perfect world that would be something like:
const func(const this, const int a,  int b) : const int; // first const
means pure, last const is for return type.
that even reduces the keyword count! (no need for pure)

but... that will not happen because it's too big a change in syntax for D.
at least i hope the "const this" above could be considered as it also
would be extensible for another use case promised for D2 - extensible
classes.

basically, of all the other rearrangement of function declaration ideas
on the NG I liked the most the one Janice, i think, suggested of using
const(this).this makes very clear what is const, however it adds another
pair of parens which is confusing. so my personal conclusion is - why
have two pairs of parens? lets unite them to the following:
int a(const this, const int a);
which is very clear on its intent, IMO.

Questions? Suggestions?

--Yigal