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.
- My suggestion of allowing to express multiple inheritance, was for c++ class declarations only, i.e. class header files only.
- 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...