Fully transitive const is not necessary

[Sean Kelly]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> Sean Kelly wrote:
> > I know you like to talk about the unreliability of const in C++ because of
> > const_cast and the like, but in my opinion those are theoretical objections
> > because I've never encountered even a single use of const_cast in actual
> > code.
> It's not even const_cast. It's simply going *one* level of indirection,
> and all the const checking is gone, gone, gone. You can have const
> objects in C++, but not const data structures.
> > So while I do agree that C++ const may not be useful for static
> > analysis, I also believe that C++ const works just fine for achieving more
> > demonstrably correct code.  For example, if I create this class:
> >
> >     class BoxedInt
> >     {
> >         int val;
> >     public:
> >         BoxedInt( int v ) : val( v ) {}
> >         int get() const { return val; }
> >         void set( int v ) { val = v; }
> >     };
> >
> > I am confident that if someone tries to call set() on a const instance of
> > BoxedInt a compile-time error will occur.  To me, this means that C++
> > const helps to write demonstrably correct code because the compiler
> > will trap at least some logic errors related to intended program behavior.
> > Sure, the user could theoretically cast away const-ness of his BoxedInt
> > object and thus break everything, but as far as I'm concerned that's his
> > problem.
> You've got no references in BoxedInt. How many data structures do you
> use that contain no references?

No references at all?  Perhaps half.  But very few of my C++ objects contain
references to external data, and references are almost always managed via
shared_ptr or the equivalent.  I can say with confidence that I've never been
bitten by a bug resulting from non-transitive const in C++.  That isn't to say
that I think there's no need for transitive const--I think it's a great idea--
but only that this hasn't been a problem in the code that I've written.

> Essentially, const in C++ only works for
> trivial objects. (I'm not saying trivial objects are not useful, I'm
> just saying they are trivial.)

I think this statement is open to interpretation.  From a theoretical perspective
I agree.  But with RAII objects managing references and the like, it's rare for
even very complex objects to contain raw pointers, and such RAII objects can
be made to fake transitivity of const by overloading their const and non-const
methods appropriately.

> >> This will become more obvious as C++ tries
> >> to compete in the multiprogramming arena. The C++ compiler *cannot* help
> >> with multiprogramming issues; the C++ programmer is entirely dependent
> >> on visual inspection of the code, making C++ a tedious, labor intensive
> >> language for multiprogramming.
> >
> > I agree with this.  C++ const is intended to catch logical mistakes and is not
> > useful for multiprogramming.
> >
> >> How many times have you looked at the documentation for a function API,
> >> and wondered which of its parameters were input and which were output?
> >
> > Never.
> Ok, but I do it all the time.

That's fine.  I recognize that I'm not singularly representative of the entire
programming world :-)

>  > Though it perhaps helps a bit that C++ classes are value types.
> They are value types, true, but I don't think that is relevant to the
> issue of transitive const.
> > I know that counter-examples could be provided along the lines of:
> >
> >     struct C
> >     {
> >         char* buf;
> >     };
> >
> >     void fn( const C val )
> >     {
> >         val.buf[0] = 0;
> >     }
> >
> > But I've never seen anyone actually make this kind of mistake.  Perhaps I've
> > just been lucky.
> So what you're saying is you follow the *convention* that const in C++
> is transitive. I suggest that this convention is the norm, and that
> normal idioms are ripe fruit for codification into the language rules.

I agree.

> I further suggest that since the C++ compiler cannot help you find any
> of those mistakes, your projects may unknowingly suffer from them. I do
> know that when I've tried to do COW in C++ (which relies on transitive
> const), there have been many bugs and it's been hard to get them flushed
> out.

Yup.

> >> When you talk about the "misapplication" of const, does that mean
> >> failure to understand what the specific API of a function is?
> >
> > Most often, the problem I've seen is for const to not be consistently applied
> > to class member functions or within the program itself.  It's been a while so
> > I'm actually fuzzy on what the exact problems were, but I remember modifying
> > a bunch of unrelated code when I created a new member function in some class.
> > If I had to guess I'd say this had something to do with the non-transitive nature
> > of const in C++ and that the class contained pointers which were being used in
> > questionable ways.
> Doesn't something used in a questionable way sound like a bug that const
> helped you find, even if it was just pointing out something that should
> be clarified and better documented?

Sure.  I'll definitely agree that the code was poorly written and not at all documented,
even if it actually worked as-is.


Sean