Normalizing Const Syntax.

[Scott S. McCoy]

On Wed, 2008-04-09 at 01:08 +0000, Graham St Jack wrote:
> 
> 
> I agree that the present syntax is a problem, but I'm not sure how
> your 
> suggestion fixes the problem.

By normalizing the syntax.  if const is transitive, then it needs to be
differentiated from other types of storage classes such a static.  My
solution simply takes the existing, currently defined syntax for
differentiating between them and makes it mandatory for all const-typed
identifiers.

const(int) foo how becomes the way of saying a const int.  Rather than
trying to reshape the syntax (which I also tried to do, but found
difficult in a number of ways) I thought maybe a quicker, and easier to
get accepted route would just be to re-purpose the existing syntax.

In fact, this syntax already exists...I'm just suggesting removing the
other, or removing it's newer definition.

> 
> The two alternatives that make sense to me are:
> 
> const ReturnType const method_name();
> 
> const ReturnType method_name() const;
> 

Right, and I've seen this suggestion.

Actually, I'm not sure any of this solves the problem.  The real issue
here is that we just have too many damn things to say with the word
const.

Maybe we should separate the concept of a const method and a const
identifier.

After all, the difference between the const and invariant method
definitions is...well...slim:

"""
Invariant member functions are guaranteed that the object and anything
referred to by the this reference is invariant.
"""

"""
Const member functions are functions that are not allowed to change any
part of the object through the member function's this reference.
"""

Isn't the goal here just that the member function doesn't modify
anything?  And why do invariant member functions even need to exist?
(Are we really going to use them?).

Maybe we could come up with a base-line that works for member functions
between the two, and ditch the use of the keyword "const" for method
declarations entirely.  Then we could have a special access class which
defines that the function may be invoked from the context of a const
*or* invariant instance.  Naturally, an invariant class means nothing
can be modifiable, but I can't imagine why "doesn't modify anything in
the this reference" doesn't suffice for functions in an invariant
context.

Cheers,
	Scott S. McCoy