www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ mutable in D

reply Michael Galuza <riddlermichael gmail.com> writes:
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()`.
Jul 30
next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 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()`.
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++).
Jul 30
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 30 July 2021 at 20:09:19 UTC, Tejas 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++).
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).
Jul 30
next sibling parent Tejas <notrealemail gmail.com> writes:
On Friday, 30 July 2021 at 21:53:01 UTC, IGotD- wrote:
 On Friday, 30 July 2021 at 20:09:19 UTC, Tejas 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++).
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).
Well, Jonathan Davies disagrees: http://jmdavisprog.com/articles/why-const-sucks.html
Jul 30
prev sibling parent reply Gollan <gollan mail.com> writes:
On Friday, 30 July 2021 at 21:53:01 UTC, IGotD- wrote:
 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.
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
Jul 31
parent IGotD- <nise nise.com> writes:
On Saturday, 31 July 2021 at 12:27:28 UTC, Gollan 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
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.
Jul 31
prev sibling parent reply Jack Applegame <japplegame gmail.com> writes:
On Friday, 30 July 2021 at 20:09:19 UTC, Tejas wrote:
 Also remember that casting away const is undefined behaviour in 
 D (unlike being defined and supported in C++).
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.
Jul 31
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 1 August 2021 at 06:15:30 UTC, Jack Applegame wrote:
 On Friday, 30 July 2021 at 20:09:19 UTC, Tejas wrote:
 Also remember that casting away const is undefined behaviour 
 in D (unlike being defined and supported in C++).
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.
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.
Aug 01
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 1 August 2021 at 06:15:30 UTC, Jack Applegame wrote:
 On Friday, 30 July 2021 at 20:09:19 UTC, Tejas wrote:
 Also remember that casting away const is undefined behaviour 
 in D (unlike being defined and supported in C++).
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.
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`: ```d 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
Aug 01
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 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()`.
Not any good analogue. There are some situation-dependant possibilities though. First one, you could do some template magic. Something like: ```d 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.
Aug 01
prev sibling next sibling parent reply Michael Galuza <riddlermichael gmail.com> writes:
On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 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()`.
Let's slightly reformulate my question. Can we write in D smth like this: ``` struct Mutable(T) { /* magic */ } struct Shape { private Mutable!double area; double getArea() const { if (area == 0) { area = computeArea(); } return area; } } ``` In other words, can we implement method `void S.opAssign(T value) const` of some struct `S` which change internal state of `S` and this method doesn't have UB and doesn't break D's type system.
Aug 01
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 1 August 2021 at 18:21:32 UTC, Michael Galuza wrote:
 In other words, can we implement method `void S.opAssign(T 
 value) const` of some struct `S` which change internal state of 
 `S` and this method doesn't have UB and doesn't break D's type 
 system.
No. Mutating an object typed as `const` is always UB in D.
Aug 01
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/1/21 2:21 PM, Michael Galuza wrote:
 On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 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()`.
Let's slightly reformulate my question. Can we write in D smth like this: ``` struct Mutable(T) { /* magic */ } struct Shape {     private Mutable!double area;     double getArea() const {         if (area == 0) { area = computeArea(); }         return area;     } } ``` In other words, can we implement method `void S.opAssign(T value) const` of some struct `S` which change internal state of `S` and this method doesn't have UB and doesn't break D's type system.
Yes. You need to use global space to do it. e.g.: ```d struct Shape { private static double[size_t] areaLookup; private const size_t magicNumber; // set on constructor double getArea() const { return areaLookup.require(magicNumber, computeArea()); } } ``` I've argued in the past that since this is possible, putting the memory inside (or along-side) the instance isn't all that different, and there are surely other typesystem-allowable ways (I think there was a plan at some point to use affixAllocator to do something like this). But "possible" here is not exactly equivalent to "desirable". What you need is some way to clarify that the "mutable" data is not actually part of the instance, but some nebulous region that is carried along with it. -Steve
Aug 02
prev sibling next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 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()`.
Not possible as other people mentioned. In this case the best approach would be to either design your struct to contain const and mutable fields, and design it's interface accordingly, or you could make a mutable decorator that would be mutable and expose mutable aspects, while keeping the decorated instance const. Best regards, Alexandru.
Aug 01
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 30 July 2021 at 19:17:55 UTC, Michael Galuza wrote:
 [snip]
We are saying that there is no direct analogue for `mutable` in D. It turns out we were all wrong - there is, and it even works in ` safe`! Behold: ```d safe: alias MutableDel(T) = safe ref T delegate(); struct Foo { int normalMember; private MutableDel!int _mutableMember; ref mutableMember() const {return _mutableMember();} this(int a, int b) { normalMember = a; _mutableMember = makeMutable(b); } } MutableDel!T makeMutable(T)(T mem) safe { auto varArr = [mem]; return ref () => varArr[0]; } void main() { import std; const foo = Foo(5, 10); foo.mutableMember.writeln; //10 foo.mutableMember = 15; foo.mutableMember.writeln; } ``` Now, I definitely don't recommend using this. It might well end up being considered as a bug, and thus stop working in the future. Also the optimizer might not take this possibility into account, thus injecting bugs to your code.
Aug 03
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 3 August 2021 at 13:02:38 UTC, Dukc wrote:
 Now, I definitely don't recommend using this. It might well end 
 up being considered as a bug, and thus stop working in the 
 future. Also the optimizer might not take this possibility into 
 account, thus injecting bugs to your code.
It's a known bug, since 2008: https://issues.dlang.org/show_bug.cgi?id=1983
Aug 03
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 3 August 2021 at 14:01:20 UTC, Paul Backus wrote:
 On Tuesday, 3 August 2021 at 13:02:38 UTC, Dukc wrote:
 Now, I definitely don't recommend using this. It might well 
 end up being considered as a bug, and thus stop working in the 
 future. Also the optimizer might not take this possibility 
 into account, thus injecting bugs to your code.
It's a known bug, since 2008: https://issues.dlang.org/show_bug.cgi?id=1983
I don't think it's that one. I'm not abusing the delegates context pointer mutablity, I'm abusing the fact that a `const` or `immutable` `delegate` may have a mutable return type: ```d safe: void main() { import std; auto varArr = [5]; immutable del = () => varArr[0]; del().writeln; varArr[0] = 10; del().writeln; } ```
Aug 03
parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 3 August 2021 at 15:33:34 UTC, Dukc wrote:
 On Tuesday, 3 August 2021 at 14:01:20 UTC, Paul Backus wrote:
 https://issues.dlang.org/show_bug.cgi?id=1983
I don't think it's that one. I'm not abusing the delegates context pointer mutablity, I'm abusing the fact that a `const` or `immutable` `delegate` may have a mutable return type: ```d safe: void main() { import std; auto varArr = [5]; immutable del = () => varArr[0]; del().writeln; varArr[0] = 10; del().writeln; } ```
This example is abusing the fact that an `immutable` delegate can have a mutable context pointer--i.e., that immutability of delegate contexts is not transitive. If you try to replace the delegate with a user-defined type... ```d struct Delegate { int* context; this(int* p) { context = p; } int opCall() { return *context; } } void main() { int* p = new int(5); immutable dg = Delegate(p); } ``` The compiler correctly points out that the conversion to `immutable` is invalid:
 Error: cannot implicitly convert expression 
 `Delegate(null).this(p)` of type `Delegate` to 
 `immutable(Delegate)`
You're right, though, that it's not exactly issue 1983. I think the bugzilla issue for this specific case is https://issues.dlang.org/show_bug.cgi?id=16058.
Aug 03