Const template

[Frits van Bommel]

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.

Let's talk about references for a bit first. You have "normal" (mutable) 
references and const references. When you create an object, you get a 
mutable reference by default, or a const reference if you ask for it 
("new const C"). Normal references implicitly convert to const 
references, but not the other way around.

I just figured that an object created by "new const" would be a "const 
object", since no non-const references to it are possible without 
invoking undefined behavior (e.g. using pointer casts). Therefore it 
can't be modified.

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

For D, you may be right because of the way modules work; the compiler 
will often have the source to all functions called.
For C++ that conjecture will often be wrong, simply because the 
implementation of functions called will often be in a source file the 
compiler can't see (it has only seen the header).

The compiler needs to either see every variable accessible from called 
functions (to make sure they can't contain or (transitively) reference 
an alias) or know for certain that no mutable references accessible to 
called functions exist (because it sees the allocation and the 
implementation of every function it may have been mutably passed to).
Or maybe there's another way to be sure it won't be modified that I 
didn't think of, but I don't think there's any way to be sure if it's 
ever been a mutable parameter to an unseen function and another unseen 
function is then called.

> So: class objects are never const. Const references only restrict 
> access, not the nature of bits on the heap.

I didn't mean "const object" to mean anything about the nature of the 
bits, I just used the term to indicate an object that has been const 
since allocation because it was allocated with "new const".