D vs C++ classes?

[Alexandru Ermicioi]

On Wednesday, 30 June 2021 at 06:23:17 UTC, Ola Fosheim Grøstad 
wrote:
>
> I don't think so, because one can grab runtime type information 
> space that isn't used by C++.
I don't have in depth knowledge of C++, but doesn't your 
statement imply that it is reserved by C++ for future use?
> In the worst  case one can just allocate space for unused 
> virtual functions and use that for other stuff.
Imho feels more like a hack.

Btw this doesn't answer the problem with mangling the method 
attributes.

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

I don't have any dips to specify at the moment, but this doesn't 
mean there can't be in the future, dips that require specific abi 
incompatible with c++ one. For example what if there is a drive 
to have interop with java, or C#, through (extern xxx) 
functionality?

> Ok, but then we risk having some libraries making all their 
> classes `extern (C++)`

And this is perfectly fine. This means that the lib is designed 
to be c++ interoperable.

> and thus forcing that onto the application programmer which 
> then cannot get D typeinfo.

This can be solved not only with just making D classes c++ 
compatible. What about enhancing D language to provide typeinfo 
wrappers over c++ ones when we ask for them with typeid statement?

Clearly with current type info architecture where all of them are 
classes won't work, but what if we'd refactor them to be a set of 
interfaces?

Compiler then would be able to spawn implementations of those 
interfaces, for 'D' classes as well as for extern c++ ones which 
would be just some wrappers over c++ 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.

I'm sorry, but I feel like this is a very skewed opinion in favor 
of c++ interoperability, ignoring everything else just to get it.

> 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.

There are no c++ classes in D. There are D classes that are 
compatible with C++ abi, which in turn does remove some features 
from them that are not representable through c++ class semantics 
(typeinfo is just not one of them).

So use extern c++ for d classes exposed outside to the c++ based 
apps that use your lib, and keep using standard d classes inside 
your lib. That's the purpose of any (extern xxx) statement.