Want reasonable reference counting? Disable automatic sharing of immutable

[Timon Gehr]

On 14.11.21 09:12, Walter Bright wrote:
> On 11/13/2021 11:16 PM, Walter Bright wrote:
>> Or maybe just give up on having immutable ref counted objects. Ref 
>> counted objects are mutable.
> 
> Let me expand on that a bit.
> 
> This conversation reminds me of the old "logical const" debate, where 
> people wanted to have constant objects that were not constant. That just 
> would not work with the notion of transitive const.
> ...

The GC is able to deallocate `immutable` data. I don't think it's 
entirely unreasonable to give that capability to @system user code as 
well, but saying `immutable` means GC or infinite lifetime is of course 
possible.

> Having a __mutable field in an immutable hierarchy is the same 
> abomination. Attempting it immediately starts causing the rest of the 
> type axioms in D to come apart.

Well, the way I imagined it to work is:

- Carefully define what the axioms are in terms of allowed equivalence 
transformations of source code.
- @trusted code that mutates __mutable data has to be prepared for any 
of those equivalence transformations.
- __mutable functions are exempt of most or all of those equivalence 
transformations.

In principle, this could work. (But of course, it would make the axioms 
more complex and may prevent an expansion of rewrites that are based on 
the simpler meaning of attributes in the future.)

> As Steven pointed out, sharing stops working.
> ...

Yes, but implicit sharing has other drawbacks, e.g., it may prevent 
thread-local GC for thread-local immutable data such as strings.

> It's like defining pi to be 3.0, and a right angle to be 89 degrees. 
> Your house will not fit together if the corners are 89 degrees.
> 
> How does C++ manage it? They don't have immutable types. Const is just a 
> documentation attribute.
> 
> How do functional languages do it? Reference counted types are not part 
> of the type system. They are behind the curtain, just like how the gc 
> works in D is behind the curtain, and associative arrays(!).
> ...

__mutable variables and functions are an attempt to formalize being 
"behind the curtain", so that the runtime ceases to be language magic 
and @system user code can have well-defined access to the other side of 
the curtain. This allows the runtime to be implemented in terms of 
straight lowering to templates without special rules.

> D has these choices:
> 
> 1. ref counted objects are mutable
> ...

Works, but you may have to extend it to "anything that's not allocated 
with the GC is mutable". Deallocation eventually will change the memory 
you pass into it.

> 2. ref counted objects are outside of the type system
> ...

For this to work, there still needs to be a careful definition what 
@trusted functions are allowed to do with data of certain qualification. 
I think adding some type system support that is strictly @system, like 
__mutable variables and functions is better than having no language 
support at all, because otherwise, in order to support reference 
counting, you may end up penalizing code that does not actually use it.

> 3. break the type system
> 
> I find (3) to be a bit ironic after D has been lambasted for having 
> inconsistent semantic rules.
> ...

Yes, I don't think adding UB to the standard library is an option.

> PS. I suspect that ref counted shared mutable objects are an indicator 
> of insanity.

Possibly, though it's hard to know everyone's use cases in advance.