Const ref and rvalues again...

[martin]

On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote:
> That is the main thing, but C++ also has a 'mutable' keyword.

Right, I forgot this inconspicuous little keyword. It really is a 
huge hole in C++'s const system.

>> If your struct doesn't support any const operations, it most 
>> likely has good reasons not to.
>
> Either that, or someone hasn't bothered to annotate.

Hehe, yeah, the latter being more likely.

> You got it exactly reverse. const harms encapsulation because 
> it exposes some details about implementations. It is often not 
> applicable in sufficiently dynamic code.

I don't see it that way. I find it very useful to know that an 
argument won't be modified. Example: suppose we have a large 
array (static array or wrapped in a struct) and need it as input 
for some independent operations. By knowing it won't be touched 
(passing by const ref) it is immediately clear that the 
operations can be run in parallel. Otherwise, one would need to 
go through the operations' implementation to determine if 
parallelization is possible.

> You do not see issues with changing the interface based on 
> implementation details?

I find it okay to require all possible changes to an argument 
passed by reference to be required to be directly visible by the 
caller, just to prevent accidentally missing side effects. 
Suppose a function takes a const reference parameter and is 
called at a site using an rvalue. After some time, that function 
is updated so that its parameter is or may be changed, changing 
the const ref parameter to a ref parameter. That may lead to big 
issues for the call sites. A compiler error would make sure the 
affected call sites are inspected and updated instead of 
potentially introducing regressions.