Sugestion for a const implementation

[Miles]

Walter Bright wrote:
> 1) there are *legal* ways to subvert it,

You mean, const_cast<> and other casts? If so, this is no reason to say
D shouldn't have similar implementation. You can implement it in D but
without allowing any way of removing const-ness from the object
reference. I never used const_cast<> or any other way of removing
const-ness from an object in 8 years of C++ coding.

If you mean subverting it by changing the object by its original
reference, or by a different non-const reference, this is another
problem, that doesn't invalidate const itself. Const applies to a
specific reference to an object, not the object itself.

If you mean by using mutables, I see no problem here also. Mutable is
not meant to be used for any attribute, just for caches and other
specific attributes that doesn't affect the object real state.

If you are afraid of programmers misusing const, by subverting it...
well... programmers also misuse operator overload, templates, delegates,
etc... what doesn't make these features wrong.

> meaning it is useless as a semantic aid

No, it is not. const is a contract that says that the function will not
change the object, at least not through *that specific reference*. This
does not mean that the object won't be changed during the function call.

> and useless to the optimizer/code generator

No solution will ever be useful to the optimizer or the code generator.
There is no way to guarantee that the state of any referenced object
will be constant, unless you kill thread support and restrict so much
what a function can do that it becomes an annoyance. Anyway, const
doesn't mean optimization, it is just a form of contract.

By the way, are you aware of the new 'restrict' keyword of C99? It
addresses exactly the optimization facet that 'const' doesn't; for
function parameters only.

> 2) it confuses a type modifier with a storage class (exhibiting muddled
> special case behaviors)

Does it? I think this is an implementation issue.

I think that in a good const implementation (not exactly compatible with
C++) the const variant of a type should be the same as the non-const
variant, just with a special "property" that restricts access, and not a
completely different type.

This means that

	class X {
		X func(Y a);
		const X func(const Y a) const;
	};

would generate a compile-time error, since both member functions are
identical once you make const a reference property, and not a different
type.

> 3) it's ugly and litters declarations

Sorry, but it is your personal opinion. This doesn't make const bad.

> 4) the use of overloading based on const is a workaround to another
> design flaw in C++

If you mean like the above case, yeah, sure. This does not mean that
this problem have no solution. I foresee a very simple solution like the
covariant return type already implemented in D. It is not that difficult.

There are three cases for returning const types:
  (1) the member function should always return a const reference,
  (2) the member function should always return a non-const reference
(like a copy operator), and
  (3) the member function should return a self-reference, respecting the
const-ness of the object reference it was called from.

For (1), we may declare:

	class X {
		const X getConstInstanceOfX();
				// always returns a const instance, to
				// self or to something else
	}

For (2):

	class X {
		X copy();	// always returns a new, non-const
				// instance of X
	}

For (3), we would need another new keyword or mechanism to mean
"conditional constness depending on 'this'". Some suggestions are
'volatile const', or 'scope const' (overloading some already-existing
keywords), or something like 'condconst', or something else.

	class X {
		condconst X opCall() const;
				// returns a self-reference, function
				// shouldn't modify object since it may
				// be called as const
	}

So, any case in which in C++ you would write a pair of identical
functions overloaded by const, you would use this third case in D.