Are D classes proper reference types?

[Ola Fosheim Grøstad]

On Friday, 25 June 2021 at 07:01:31 UTC, kinke wrote:
> Well AFAIK it's mandated by the language, so an RC scheme 
> replacing such allocations by heap ones seems like a definite 
> step backwards - it's a useful pattern, and as Stefan pointed 
> out, definitely in use. You could still stack-allocate but 
> accommodate for the counter prefix in the compiler.

Yes, but then I need to mark it as non-freeable.

> It's certainly possible as it's a library thing; some existing 
> code may assume the returned reference to point to the 
> beginning of the passed memory though (where there'd be your 
> counter). What you'd definitely need to adjust is 
> `__traits(classInstanceSize)`, accomodating for the extra 
> counter prefix.

Yes, if people don't make assumptions about where the class ends 
and overwrites some other object, but I suspect pointer 
arithmetics isn't all that common for classes in D code.

> There's very likely existing code out there which doesn't use 
> druntime's emplace[Initializer], but does it manually.

I guess, but the compiler could have a release note warning 
against this.

> ctor. It's probably easier to have the compiler put it into 
> static but writable memory, so that you can mess with the 
> counter.

Another reason to add the ability to mark it as non-freeable.

> All in all, I think a more interesting/feasible approach would 
> be abusing the monitor field of extern(D) classes for the 
> reference counter. It's the 2nd field (of pointer size) of each 
> class instance, directly after the vptr (pointer to vtable). I 
> think all monitor access goes through a druntime call, so you 
> could hook into there, disallowing any regular monitor access, 
> and put this (AFAIK, seldomly used) monitor field to some good 
> use.

Yes, if you don't want to support weak pointers. I think you need 
two counters if you want to enable the usage of weak pointers.

One reason to put it at a negative offset is that it makes it 
possible to make it fully compatible with shared_ptr. And then 
you can also have additional fields such as a weak counter or a 
deallocation function pointer.

I don't think maintaining the D ABI is important, so one could 
add additional fields to the class. Maintaining core language 
semantics shouldn't require ABI support I think.