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