Rebooting the __metada/__mutable discussion

[Alexandru Ermicioi]

On Friday, 8 April 2022 at 14:23:01 UTC, H. S. Teoh wrote:
> On Fri, Apr 08, 2022 at 01:50:01PM +0000, Alexandru Ermicioi 
> via Digitalmars-d wrote:
>> On Wednesday, 6 April 2022 at 09:41:52 UTC, RazvanN wrote:
>> > ...
>> It may be a dumb and already discussed question, but what's 
>> the problem of making rc counted structs mutable only?
>> 
>> In this way, you won't have the dilemma of circumventing the 
>> immutable/const system, to just increment the counter, or any 
>> metadata.
>> 
>> Note: the payload of rc struct, may be const or immutable if 
>> needed.
> [...]
>
> In theory, this would IMO be the right approach.  However, it 
> does hamper usability. For example, you could no longer write:
>
> 	auto myFunc(in RC!Data data) { ... }
>
> but you'd have to write instead:
>
> 	auto myFunc(RC!(const(Data)) data) { ... }
>
> because RC!... has to remain always mutable.

Nicer version: RC!(const T)
Though that is true.

>
> Some of the nice implicit conversions would also no longer work 
> as
> desired, e.g., RC!Data would not implicitly convert to 
> RC!(const(Data)),
> where with GC'd data, Data* implicit converts to const(Data)*. 
> This
> asymmetry makes metaprogramming harder to work with RC.

Can't alias this be employed for this?

I.e. in Rc struct have this:
alias this = asQualified;

Where asQualified returns version with suitable modifier.

>
> Things get worse once you have nested structures, e.g.:
>
> 	struct SubData {...}
> 	struct S {
> 		RC!SubData data;
> 	}
>
> Now you couldn't pass S to anything that takes const, because 
> transitivity of const would force RC!SubData to be 
> const(RC!SubData), which breaks the refcounting mechanism.
> Basically, once you have RC!xxx in any subpart of your data 
> structure, it "reverse-infects" the entire data structure with 
> mutable, because you can no longer use const on any containing 
> part of the structure, since it would break RC.

True, it won't be easy to use RC as fields, but could we ignore 
this problem for initial implementation, by prohibiting immutable 
versions?

You can always extend RC structs to support immutable/const 
qualifiers on itself.

I keep reading this forum for a long time, and always see only 
discussions about rc structs and etc, but no viable solutions. 
Perhaps it's better to try implement a restricted version of it 
first? i.e. only mutable rcs?