DIP 1018--The Copy Constructor--Formal Review

[Walter Bright]

On 2/24/2019 8:04 PM, Manu wrote:
>> 1. make code easier to understand?
> 
> const code is self documenting and protective against modification by
> issuing the user helpful error messages.

I've had many people tell me they mean transitive const when they use const in 
C++. That is not self documentation. Nor is it very helpful. The very fact that 
const code compiles in C++ and surprises people when it doesn't compile in D 
shows the misunderstanding it engenders in C++ code. People infer that it is 
transitive when it is not.

Really, of what value is it to know that only the head can't be changed, with no 
information about the rest?

An interesting manifestation of this uselessness in C++ is the notion of 
"logical const", where a supposedly "const" value is lazily set to a value upon 
first use. I.e. it isn't const, it's just pretend const.


>> 2. prevent common programming bugs?
> 
> You can't modify const data, for instance,

I know technically what it does. But that wasn't my question.


> a copy constructor can't freely modify the source value...

C++ copy constructors are not required to declare the source as const:

"A non-template constructor for class X is a copy constructor if its first 
parameter is of type X&, const X&, volatile X& or const volatile X&, and either 
there are no other parameters or else all other parameters have default arguments"
  -- CPP98.12.8

Again, I know technically what it does. Not the value of it. I used C for a 
decade before const was introduced. I tried using it, and discovered that head 
const added nothing much of any value and I stopped bothering with it.


>> 3. help with multithreaded coding problems?
> 
> This is a different conversation about `immutable` and `shared`.
> `const` doesn't say anything about D's decisions relating to
> thread-locality by default, which obviously still applies.

'immutable' data is implicitly shareable. Const allows the same functions to 
work on both shared immutable and non-shared mutable data. C++ has no way to say 
a function can work on both kinds of data, or even how to describe such data.


>> 4. improve code generation?
> Not a lot.

Actually, not at all. C++ const is useless for code generation because:

1. people cast away const (yes, they do!). I learned this the hard way and had 
to back out those optimizations.

2. other references may mutate it.

Because of (2) it is similarly useless in D, however, it allows the same 
functions to work on immutable and mutable data, and that does have value. (The 
optimizer can make use of immutable.)


> I mean, you speak as if `const` is a synonym for `mutable` in C++...
> const things are const.

Not only are they not (legal to cast it away!), they can be mutated by other, 
non-const pointers. (There's no way to specify "pointer to immutable" in C++.)
Furthermore, const tells you nothing about the rest of the data structure. C++ 
const is all fine if your data structure fits entirely in one struct. It's 
rather meaningless for more complex objects. You cannot write generic code:

     void doSomething(T)(const T x) {...}

and rely on it to not modify T if T is a non-trivial object.


> Alternatively, if const were spec-ed similar to C++ const, it would be
> very easy to implement TransitiveConst!T as a tool.

You could specify it, but you couldn't use it. (There'd be all kinds of implicit 
conversion problems.) There's good reason why const is treated specially for 
overload resolution and implicit conversion. I.e.:

     void foo(const T const * const * const * p);
              const T       * const * const * q;
     foo(q); // oops!

----

One thing I quite agree with you on, though, if you really want to modify 
non-trivial const objects, then D's const isn't for you :-) If you don't believe 
the rewards of carefully designing the data structures and functions that 
operate on them so they can be const is worth it, then D's const isn't for you. 
For me, I think it is worth it. And yes, it ain't easy, as old habits die hard.