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.
