Fully transitive const is not necessary

[Walter Bright]

Sean Kelly wrote:
>> If C.name were invariant, there would be no need for any locks. I don't
>> think this is a good example, because with D's invariant strings there
>> is no need for such locking.
> Also, I believe my example demonstrated that memory fences and order
> of evaluation issues are still a concern with invariants.  They aren't a
> magical safe ticket to lock-free programming land.

While creating an invariant is something that should be done with care, 
once it is created, locks are no longer needed on it. After all, since 
it cannot change, where is the need to sync it?

> Let me re-iterate my point by saying that the /only/ feature provided by
> invariants is that once invariant data is shared through a properly
> synchronized method, the invariant is guaranteed not to change out from
> under the viewer.  This is identical to the guarantee provided by returning
> a copy of the same data when it is requested.  Invariant references simply
> guarantee that any copying will be done up front, automatically, so it does
> not have to occur manually later on.

You're right that invariants can give equivalent semantics to always 
getting a local copy.

> In general, I feel that the amount of copying caused by invariants is greater
> than without them in a typical program,

I'm not convince of that. Invariants make sharing much more possible and 
practical, because one doesn't have to worry about making a local copy 
to protect it from some other alias.