D vs C++ classes?

[Ola Fosheim Grøstad]

On Wednesday, 30 June 2021 at 00:07:46 UTC, Alexandru Ermicioi 
wrote:
> This will basically cut any research and potential improvements 
> into the compiler regarding oop that rely on type information 
> being coded inside abi, right?
> Should we sacrifice any possible future improvements for this?
> What about additional annotations that are embedded in mangled 
> name for the class methods?

I don't think so, because one can grab runtime type information 
space that isn't used by C++. In the worst  case one can just 
allocate space for unused virtual functions and use that for 
other stuff.

> I personally don't think this is right approach. We basically 
> are running after C++ to just add this interop stuff, while 
> limiting ourselves in growth of oop aspect of D.

I understand this sentiment, but what growth are you thinking of, 
though?

> I think the best alternative here would be to allow c++ class 
> declarations (extern c++ ones) to be able to express multiple 
> inheritance and other things related to c++ classes, rather 
> bounding native D classes to c++ abi.

Ok, but then we risk having some libraries making all their 
classes `extern (C++)` and thus forcing that onto the application 
programmer which then cannot get D typeinfo. So that is worse for 
the programmer, as he is then stuck with C++ typeinfo and lost 
out on whatever advantages D can add to C++-classes.

For instance, I dislike having 3 different record-types: struct, 
class, C++-class. So I would probably just use "extern (C++) 
classes" when I need virtuals, "structs" otherwise and avoid "D 
classes"... What will happen when the eco-system grows? That is 
the tricky question.