D vs C++ classes?

[Ola Fosheim Grøstad]

On Wednesday, 30 June 2021 at 09:19:28 UTC, Alexandru Ermicioi 
wrote:
> I don't have in depth knowledge of C++, but doesn't your 
> statement imply that it is reserved by C++ for future use?

No, but ABIs can change obviously, so there is that.

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

Not sure what you mean here. You can have multiple names for the 
same entity?

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

Yes, but you get a split eco system.

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

It is possible to use fat pointers, but there is overhead.

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

Not sure how this would work?

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

Ok, but I think D has to make up its mind of whether C++ 
interoperability is going to be a goal and a selling point, 
meaning close to full interop, or just a bumper sticker.

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

I don't understand what you mean here, if you have extern c++ 
with full interop then you have c++ classes (runtime), but 
without things like multiple inheritance then D provides a subset 
of the c++ class type space.

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

But using D classes won't provide any real benefits for most 
programmers, so why bother? Also, can we assume that you know a 
priori what you need to send over to C++?