[Dlang-study] [lifetime] Few root decisions to take on RC classes

[Jakob Bornecrantz]

On Monday, 2 November 2015 at 15:35:01 UTC, Andrei Alexandrescu 
wrote:
> On 11/02/2015 10:31 AM, Martin Nowak wrote:
>> On Friday, 30 October 2015 at 21:31:56 UTC, Andrei 
>> Alexandrescu wrote:
>>> * @rc classes shall not be single-rooted. Rationale: there is
>>> no strong advantage in it and it would force all @rc classes 
>>> to
>>> embed a vptr. This has been already discussed and largely
>>> agreed upon in this group.
>>
>> I this really such a good idea to it simply b/c it's possible?
>> It would kind of add a third species to struct/class, implying 
>> lots of
>> work (compiler changes, debuggers, typeinfo...).
>> And unless you want to break typeid(baseclass) which currently 
>> returns
>> the dynamic type you wouldn't even safe the pointer.
>
> Fine by me. Walter's and my thinking was we want to allow 
> minimal overhead refcounting if possible. I'd say we can have a 
> vptr in the implementation but should be careful about 
> requiring it by design. -- Andrei

My aversion to vptr-less classes isn't so much the concept itself,
it has it uses and place, its just that the current semantics of
"@rc class Foo" also implies cpp style class implicit 
polymorphism.
Because in D a class declaration has a set of semantics with it.

Consider (where disable explicitly removes the vtable):

class Foo {}               // regular class
@rc class Foo {}           // regular rc class
@rc class Foo : disable {} // vptr-less rc class

Gives us that declarations that are syntactically closer are
also semantically closer to each other. It also allows for
enforcing of no virtual functions in the class body.

This all made sense in my head I hope it turns out well
in text for as well.

Cheers, Jakob.