logical const is a subset of transitive const

[Janice Caron]

On 9/14/07, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
I can't argue with your reasoning.

...but...

It's a paradigm thing. Logical const is all about *interface*;
physical const is all about *implementation*.

If keywords existed for both paradigms, I think there would only be
more confusion. Writers of classes would have to choose between
viewpoints, and there would be no consistency.

For example, suppose I have a Date class, with a function
getMonthLong. Should it be declared as:
const string getMonthLong()

or as
lconst string getMonthLong()
?

For sake of argument, let's say my first implementation is physically
const. Should I declare it const to reflect that? Or should I declare
it logically const so that I can change the implementation at a later
date?

If I choose "const", then I am implicitly saying "it is safe for
multiple threads simultaneously to reference the same instance of
const(Date) without mutex locking". So programmers would be free to
use the class in just that way. If I choose "lconst" then I am
implicitly saying "it is /not/ safe".

Why would I want to declare it not threadsafe, when it in fact, is?
Because of the possibility that I might change the implementation
later? What if I don't plan to. Am I allowed to change my mind.

It turns out, the answer is no. Suppose I chose to go with const,
reflecting the current, physically const, implementation, and people
start writing code with it. Suppose then that at a later date I change
the implementation so it's now no longer physically const. Then I'd
need to change the declaration to lconst or it wouldn't compile. But
that wouldn't help all the people who are already using my class in
multithreaded applications - particularly becase, as Walter is fond of
pointing out, this circumstance is not compiler checkable. All the
hapless programmer would know that, at some time after upgrading to
the latest version of Date, their program randomly crashes in an
almost-impossible-to-diagnose way.

In summary - we've already got two keywords for constness (const and
invariant), and that's already one too many from the point of view of
seeming confusing. I'd rather not see another one.