Is there any analogue of C++ mutable in D? As far as I understand, this is impossible due to transitive constness, but maybe some variation of Rebindable will be useful?

P.S. Of course I mean 'fair' mutable, not qualifier-away cast().

On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:

Nope. No logical const, head const, or tail const in D; just pure transitive const.

Also remember that casting away const is undefined behaviour in D (unlike being defined and supported in C++).

On Friday, 30 July 2021 at 20:09:19 UTC, Tejas wrote:

Thank you D for not having "mutable" as in C++. I don't see mutable often in C++ and is one of those corners in C++ that I don't think make much sense.

const is const, easy. In C++ const might not be ROMable. In D immutable is ROMable and transistive const helps this (unless there is some escape hatch I don't know about).

On Friday, 30 July 2021 at 21:53:01 UTC, IGotD- wrote:

Well, Jonathan Davies disagrees:
http://jmdavisprog.com/articles/why-const-sucks.html

On Friday, 30 July 2021 at 21:53:01 UTC, IGotD- wrote:

I'm really surprised you think it doesn't make much sense. What about:

• Locking a mutex to avoid data races when returning a class member from a const getter function
• Lazy resource allocation (caching) on first call of a const member function

On Saturday, 31 July 2021 at 12:27:28 UTC, Gollan wrote:

They way I look at it if you don't want the code alter the memory location then it must be immutable/const. The way you describe it, it is based on what the API expect to do with the object even if there might be internal memory writes, like the semaphore example.

With structures where members are expanded into the structure, then they share the memory location and partial const in my opinion should be prohibited. Now this can be different with classes as members are allocated independently but I'm sure about the practical benefit.

It boils down to what we expect const to represent. I used the word ROMable for a reason meaning the allocated memory should not alter.

On Friday, 30 July 2021 at 20:09:19 UTC, Tejas wrote:

No.
Casting const away IS NOT undefined behavior in both D and C++.
Modifying a const object IS undefined behavior in both D and C++.
There is not much difference between D and C++ in that way.

On Sunday, 1 August 2021 at 06:15:30 UTC, Jack Applegame wrote:

Not in C++, when the const object modification is taking place via member variables declared as mutable accessed from a const member function.

This is also a thing in Swift and Rust, by the way, they just use other mechanisms to do the same.

On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:

Not any good analogue. There are some situation-dependant possibilities though. First one, you could do some template magic. Something like:

template constIf(bool cond, T)
{ static if(cond) alias constIf = const(T);
  else alias constIf = T;
}

struct AType(bool isConst)
{ constIf!(isConst, int[]) a;
  constIf!(isConst, int[]) b;
  int[] iPretendToBeMutable;
}

Second possibility is that you store the mutable "element" in some external data structure, and store it's key or index in the const struct/class. This is what I'd probably do.

On Sunday, 1 August 2021 at 06:15:30 UTC, Jack Applegame wrote:

In D, casting away const from a pointer and mutating the pointed-to object is UB even if the object it points to was not originally declared as const or immutable:

int n 123; // mutable object
const(int)* pc = &n;
int* pm = cast(int*) pc;
*pm = 456; // undefined behavior

In C++, the above is allowed.

Source: https://dlang.org/spec/cpp_interface.html#comparing-d-immutable-and-const-with-cpp-const