Hmm - about manifest/enum

[Steven Schveighoffer]

"Walter Bright" wrote
> Janice Caron wrote:
>> On 12/31/07, Steven Schveighoffer wrote:
>>> Except in the case of class references, right?  I find this to be the 
>>> most
>>> unacceptable ommision.
>>
>> But when are you /ever/ going to need such a thing in a real-life use
>> case, that you couldn't just code differently?
>
> Going through the thought process, I finally realized that a true 
> reference type (which is what classes are) should look to the user like a 
> value type, i.e. the reference part should not be separable from the 
> value.

I'm not asking to have the value seperable from the reference.  I'm asking 
to have the ability to modify the constness of the value seperately from the 
constness of the reference.

>
>> I thought that ommission was bad at first too, until I thought it
>> through. But Walter's right - its absence doesn't present any real
>> programming problems. There's really nothing you can't just do another
>> way. By contrast, its presence would really screw up the type system.
>> Weighing up the pros and cons, I'd say its better to live with this
>> than have to deal with all the complication that
>> mutable-ref-to-const-heap-data would entail.
>
> It's interesting how having fully transitive const seems to affect the way 
> you code and your notions about coding.

I have no problem with fully transitive const, and I think it's a much 
better improvement over C++.  I originally thought fully transitive const 
was an error, because there are rational reasons to want to have 'logical' 
const.  But in reality, logical const is just not const, and should be 
treated that way.

But the difference here is, having to port code due to transitive const does 
not add code bloat or affect runtime execution.  Having to port code due to 
not having tail-const class references does.

-Steve