Fully transitive const is not necessary

[Sean Kelly]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> Invariants won't remove the need for mutexes and the like, but
> invariants themselves won't need to be wrapped inside mutexes.
> Furthermore, accessing invariants won't need to consider memory fences
> and order of evaluation issues.

I don't know how to view topics as threaded with this web client so I'll
assume you're responding to me.  From the above, does this mean that
you're taking back what you said previously:

> 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.

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.

In general, I feel that the amount of copying caused by invariants is greater
than without them in a typical program, but invariants have the advantage
of making this copying automatic.  Java strings, for example, are ostensibly
invariant (even though this can be subverted by the clever programmer), so
experience with them there can be directly applied to invariant strings in D
(Java memory model notwithstanding).


Sean