D vs C++ classes?

[Alexandru Ermicioi]

On Wednesday, 30 June 2021 at 12:22:07 UTC, Ola Fosheim Grøstad 
wrote:
> Do you mean using a function call to obtain specific type info?

Well, it doesn't matter what happens under `typeid` call, it can 
either be some inlined code that fetches the typeinfo object or 
call to a templated function. Note I don't suggest changing the 
way how type info are generated, or where they are being stored, 
only that they should be hidden and available only through a set 
of interfaces found in object module.

>> If you want full 100% interop, just use c++. There is bound to 
>> be shortcomings in interoperability, and imho we should not 
>> sacrifice the language, just for that. If this will be the 
>> future orientation for D I don't see the point of it having 
>> letter D, let's just rename it to C++++
>
> Runtime compatibility does not equate compile time limitations, 
> so it isn't really all that limiting given the current D 
> semantics. The difference between D and C++ on the compile time 
> level isn't really touched.

True we can make the compiler emit c++ compliant abi classes for 
non extern c++, but this creates a risk of falling into situation 
where all devs will just skip adding extern c++ the class 
expecting that 'it should work' while it may not to.

> You need to be able to specialize C++ classes in order to have 
> full C++ library interop. So it is a given requirement that you 
> need to be able to declare/define/instantiate extensions of C++ 
> classes in D, in order to have basic C++ interop.

I think this is already supported by D? You can already extend a 
C++ class, this still doesn't mean we should support all C++ 
class features because of that. The derived class will still be 
an extern (C++) D class even if the parent is a C++ class. I 
guess in this case interoperability should also be at inheritance 
level.

>> Let's not conflate two distinct domain objects into one. There 
>> is a class that is written in D, and there is one written in 
>> C++, they are not the same thing.
>
> You need to be able to extend the one in C++ from D in order to 
> integrate, so it basically is the same thing.
>
> Most modern C++ libraries are also heavily templated so to have 
> basic interop you actually need to translate D code to C++.
>
> That is, if C++ interop is a goal. Most people don't want 50% 
> interop they expect close to 99% interop. If only 50% is the 
> goal, then maybe just stick to C interop and forget about C++, 
> most people don't care for 50% anyway.
Which leads us to conclusion, that we can't afford a 99% interop 
between C++ and D, unless someone is ready to pour lots of 
resources into supporting templated code.

The point I try to make is, that we shouldn't equate D classes to 
C++ classes, at language level nor on abi level. This will be 
similar to how D went with all classes should inherit from a 
common Object ancestor logic, which was found to be problematic 
for D users, since it added constraints on the integration with 
other features of D language, such as @safe, pure or etc. 
Basically C++ interop should be opt in, as it is now, where you 
can declare a class that it can interface with C++ code.