DIP 1018--The Copy Constructor--Formal Review

[Manu]

On Sun, Feb 24, 2019 at 6:35 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> I agree with your point that C++ const can be used in a lot more places than D
> const. Absolutely true.
>
> Missing from the post, however, is an explanation of what value C++ const
> semantics have. How does it:
>
> 1. make code easier to understand?

const code is self documenting and protective against modification by
issuing the user helpful error messages.


> 2. prevent common programming bugs?

You can't modify const data, for instance, a copy constructor can't
freely modify the source value...


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

Maybe you're trying to argue that a const object which contains an
escape-pointer to mutable data may lead to races? But that's not the
case, because all data is thread-local in D, so there's no races on
the mutable data either way unless it's `shared`... and then we need
to refer back to the thread I created months ago where `shared` is
useless and broken, and we REALLY need to fix that. (that is; `shared`
must have NO READ OR WRITE ACCESS to data members, only shared
methods, otherwise it's completely hollow)


> 4. improve code generation?

Not a lot. But this is a red-herring; D's const won't improve code
generation where it's not present in the code.
Contrary to C++, D has a much higher probability of seeing the whole
AST and not encountering opaque extern barriers, which means it would
be relatively easy for D to recognise that the const object contains
no pointers to mutable data (assessed recursively), and then enable
any such optimisations that const offers to D today.


> I know technically what it does (after all, I implemented it), but its value
> escapes me.

I mean, you speak as if `const` is a synonym for `mutable` in C++...
const things are const. It is however possible that they contain a
pointer that leads out of the const data back into the mutable world,
and that's *desirable* in a whole lot of circumstances. Take that
away, and we arrive where we are in D.

It's also easy to NOT have pointers to mutable data escaping const
objects; make them const too!
If you want to implement a semantic where the const-ness of a member
tracks the const-ness of the owner, maybe we can apply `inout` to
behave that way.
Assuming we apply rules similar to C++, it looks like:

  const(S) const_s; // const instance of S
  struct S
  {
    int* a; // becomes `int const(*)`
    const(int)* b; // const(int*)
    inout(int)* c; // becomes const(int*) (or immtable(int*), etc)
  }

Alternatively, if const were spec-ed similar to C++ const, it would be
very easy to implement TransitiveConst!T as a tool. By any of these
means, could deploy it deliberately instead of unwillingly.