Want reasonable reference counting? Disable automatic sharing of immutable

[Timon Gehr]

On 14.11.21 22:50, Elronnd wrote:
> On Sunday, 14 November 2021 at 18:24:00 UTC, Timon Gehr wrote:
>>> 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".
> 
> Static data can be immutable too.
> ...

True, and you can also just leak. I did mention that in my other post, 
but I forgot to add it here, thanks!

> 
>>> 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.
> 
> I assumed that 'outside of the type system' meant 'language-level 
> support for reference counting'; a a type with opaque representation, 
> like a hash table.
> ...

Yes, I guess that's another way to go about it, but I think less 
language magic is better. Especially with reference counting, you may 
want to have detailed control over the allocator and/or the strategy for 
storing reference counts.

> 
>>> 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.
> 
> GC really makes more sense for multithreaded programs.  Travis downs 
> mentions at 
> https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html.  
> IMO if you are sharing mutable data between threads, and you can't stand 
> gc for some reason, then it's perfectly legitimate to make you manage 
> the lifetime yourself.

Also fair.

However, I think having the language provide some tools to implement 
stuff that's at the same level as the language runtime does make some 
sense for a systems programming language. E.g., see 
std.experimental.allocator. It would be a pity if the language hobbled 
that library by having uncircumventable pitfalls.