Const template

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> Frits van Bommel wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Frits van Bommel wrote:
>>>
>>>> But as I mentioned, there will only be const references to const 
>>>> instances, so that would mean const objects couldn't be explicitly 
>>>> deleted.
>>>> And there are people who prefer or need to work with GC off. This 
>>>> limitation would deny them the use of const objects (unless they 
>>>> like memory leaks ;) ).
>>>
>>>
>>> I disagree. If you want to disable the GC, that doesn't mean you 
>>> can't use const. You use a private non-const reference for ownership 
>>> purposes, and you use a const reference for publishing purposes:
>>
>>
>> <pedantic> I said const *objects*, not const references. </pedantic>
> 
> 
> This is actually a great point. In the case of classes, is const a 
> property of the value, or a property of the reference through which the 
> value is accessed?
> 
> This philosophical-sounding question leads actually to radically 
> different implementations. If you associate constness with the value, 
> then you have true immutable values. This was, at a point in the history 
> of humankind, Walter's opinion of a good starting point for talking 
> about const: true ROMable values. However, that approach is too rigid to 
> be useful: too rarely you have truly immutable data, but most often you 
> want to make sure that certain parts of a system *think* data is immutable.
> 
> A relaxation of that concept therefore is to associate constness with 
> the reference through which the value is accessed. Then you have much 
> more flexibility in that you can have some mutable object, pass it to a 
> function through a const handle (thus knowing that that function can 
> never change it), and then continue enjoying mutable access to that object.
> 
> The downside of this relaxation is that aliasing might stick its nose. 
> My conjecture is that in the vast majority of cases it can be trivially 
> proved (by the compiler) that no aliased access can affect const data. 
> And even in the cases where the compiler must generates conservative 
> code (as it does today in 100% of the cases), the benefit to the 
> programmer still justifies this more relaxed view of immutability.
> 
> So: class objects are never const. Const references only restrict 
> access, not the nature of bits on the heap.


All sounds good to me. Bring it on :D