On Tuesday, 29 June 2021 at 06:52:03 UTC, Ola Fosheim Grøstad wrote:

This will basically cut any research and potential improvements into the compiler regarding oop that rely on type information being coded inside abi, right?
Should we sacrifice any possible future improvements for this?
What about additional annotations that are embedded in mangled name for the class methods?

I think the best alternative here would be to allow c++ class declarations (extern c++ ones) to be able to express multiple inheritance and other things related to c++ classes, rather bounding native D classes to c++ abi.

Best regards,
Alexandru.

On Wednesday, 30 June 2021 at 00:07:46 UTC, Alexandru Ermicioi wrote:

I don't think so, because one can grab runtime type information space that isn't used by C++. In the worst case one can just allocate space for unused virtual functions and use that for other stuff.

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

Ok, but then we risk having some libraries making all their classes extern (C++) and thus forcing that onto the application programmer which then cannot get D 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.

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.

On Wednesday, 30 June 2021 at 06:23:17 UTC, Ola Fosheim Grøstad wrote:

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

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?

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

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.

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.

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.

On Wednesday, 30 June 2021 at 09:19:28 UTC, Alexandru Ermicioi wrote:

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

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

Yes, but you get a split eco system.

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

Not sure how this would work?

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.

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.

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

On Wednesday, 30 June 2021 at 09:19:28 UTC, Alexandru Ermicioi wrote:

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

Is this a problem, can't you have multiple names for the same entity in the object file?

Yes, but you get a split eco system.

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

Not sure how this would work?

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.

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.

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

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

On Wednesday, 30 June 2021 at 09:53:31 UTC, Ola Fosheim Grøstad wrote:

Ok, wasn't aware of that.

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

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.

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

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.

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

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

On Wednesday, 30 June 2021 at 10:38:36 UTC, Alexandru Ermicioi wrote:

Do you mean using a function call to obtain specific type info?

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.

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.

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.

std::function is just a buffer, but yes, D does need something comparable although in C++ std::function is a last resort, you would typically use a template instead.

On Wednesday, 30 June 2021 at 12:22:07 UTC, Ola Fosheim Grøstad wrote:

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.

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.

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.

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.

On Wednesday, 30 June 2021 at 14:13:23 UTC, Alexandru Ermicioi wrote:

That is a fair point. A 50% solution won't work for future and upcoming C++ libraries, only for older libraries (which eventually disappear).

I actually think D has to make a strategic choice, either support C++ really really well, or depart from C and C++ and provide some novel useful features.

On Thursday, 1 July 2021 at 11:26:23 UTC, Ola Fosheim Grøstad wrote:

D should not forget the original intention:
D is a system level language.

C++ is our good friend.
I always say compete with C++ and learn from C++.
Better C++ is always good for attracting people.

Recently, I find V language, and its many feature are copying from D language,though Go++,rust--.
And now they have 24000 star.
I always say Better C++ is the right way.