Want reasonable reference counting? Disable automatic sharing of immutable

Timon Gehr timon.gehr at gmx.ch
Mon Nov 15 12:34:03 UTC 2021


On 15.11.21 08:05, Walter Bright wrote:
> On 11/14/2021 1:12 PM, Steven Schveighoffer wrote:
>> First, I'll note that `__mutable` on its own is perfectly sound.
> 
> I don't think so. It produces two kinds of immutability - one with 
> mutable members, one with not. Different rules apply.
> 
> But then what do you do with opaque types? The compiler doesn't know 
> which kind of immutable they are. So it is forced to go with the worst 
> case - immutables are mutable. And it all falls apart.
> 

My answer to this was nondeterministic semantics. Just say what all the 
rewrites are that the compiler is allowed to do. Then @trusted __mutable 
functions have to ensure they function correctly _even if_ optimizations 
change the specific __mutable function calls and their arguments.

Another example of nondeterministic semantics is implicit moving. The 
compiler can either move directly or just copy construct and destroy. 
Then, the type itself has to ensure it does not matter for overall 
correctness which specific set of operations is applied even if they do 
not result in exactly the same bit patterns. This works and similar 
nondeterministic semantics can be made to work for __mutable data.

Of course, this is more technically involved than just saying 
"`immutable` means immutable" (a rare feat for D keywords), but you 
still have to address the issue of deallocation anyway.


More information about the Digitalmars-d mailing list