🚀 go-pugleaf

Background information to this posting was in a very recent summary.

Is ~const really needed?  I have scoured the replies, looking for
alternative ways to accomplish similar objectives without extending
the language.  The most obvious way to achieve the functionality of
~const is to cast constness away on a case by case basis.  The only
other alternative was described by Jim Adcock <jimad@microsoft.uucp>,
who brought up the following suggested scheme, mainly to show
how absurd it is.

Say you want to implement the equivalent of ~const data members.  If
you want to avoid casting away const, which is implementation-
dependent, you have to set up two classes which are <identical in all
respects except that in one, all members are non-const, and in the
other, all data members are const except the ones that you want to
behave as if they were ~const.  Then when what you want is the const
version of the class, you declare an object of the latter class;
otherwise, you declare an object of the former class.

Then if you want to make things a bit neater, you can declare two
smaller classes: one with all the members that are always ~const, and
the other with the members that can be other const or not.  This makes
it easier to maintain consistency between the two classes of the
previous paragraph.

Are there any other alternatives?
--
  Tom Ngo
  ngo@harvard.harvard.edu
  617/495-1768 lab number, leave message