Fully transitive const is not necessary

[Walter Bright]

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


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

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


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