D vs C++ classes?

[Alexandru Ermicioi]

On Wednesday, 30 June 2021 at 09:53:31 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 30 June 2021 at 09:19:28 UTC, Alexandru Ermicioi 
> wrote:
>> Btw this doesn't answer the problem with mangling the method 
>> attributes.
>
> Is this a problem, can't you have multiple names for the same 
> entity in the object file?

Ok, wasn't aware of that.

>> And this is perfectly fine. This means that the lib is 
>> designed to be c++ interoperable.
>
> Yes, but you get a split eco system.

I don't think so. What will be split in there?

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

If you open object.d and check for TypeInfo symbols you'll notice 
that they are final classes. We should replace them with a set of 
interfaces (with nice names without uncompliant underscores by 
code style standards), and then let d compiler generate an 
implementation for each class it has compiled. This as said will 
allow us flexibility at providing type info for not just types 
used in the language itself, but also for type declarations of 
libs that are written in foreign language, and for types written 
in d and intended for use by code written in foreign language, 
such as C++. This will also make it quite easier to add interop 
with other languages. It would be awesome if java and C# could be 
added.

When you'll invoke typeid, it will return the type info 
interface, or if it is sure that the variable contains a concrete 
type, and not a subtype, it may return the implementation of type 
info interface itself.

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

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

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

1. My suggestion of allowing to express multiple inheritance, was 
for c++ class declarations only, i.e. class header files only.
2. Making them compatible with C++ abi doesn't imply that they 
are c++ classes, and hence should support all c++ features. They 
are still D classes or a subset of them that can be called by c++ 
code.


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

Again this is a very skewed opinion that D is used only by C and 
C++ devs. I am PHP, and Java developer, and I want for D language 
to prevent me from doing stupid things with multiple inheritance 
such as the diamond problem. Hence I'm against it for supporting 
as core feature of OOP in D. It may be ok, if it is supported for 
c++ class declarations when you need to express a class hierarchy 
found in a lib written in c++.

> If there were substantive differences between D classes and C++ 
> classes with virtuals, then one could argue that it would be a 
> big loss. But I only see minor differences...

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.

Let's also clarify what full interoperability means. Per my 
understanding, this means that I can use all of libs written in 
c++, and then I can expose my D code to the c++ libs and allow 
them use it, but it does not mean, that I need to follow the c++ 
rules for the oop, or any other feature, otherwise, why not 
replace D lambdas, with std::function from c++? We need full 
interoperability...