Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend?

On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
> Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend?

Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least.

So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it.

- Jonathan M Davis

On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote:
> On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
>> Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend?
>
> Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least.
>
> So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it.
>
> - Jonathan M Davis


rust does it just fine without slicing, and supports both static dispatch and dynamic dispatch through the same interface.

http://blog.rust-lang.org/2015/05/11/traits.html

honestly, this is one of the worst parts of D. Being forced to code a certain way because it might be misused is the equivalent of digital socialism.

On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote:
> On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
>> Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend?
>
> Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least.
>
> So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it.
>
> - Jonathan M Davis

Is there any place better to go to learn about C++ support than the old dlang.org writeup?  My C++ knowledge isn't strong enough to just figure it out through experimentation, but there are some libraries I would like to link to.

On Friday, 15 May 2015 at 19:51:09 UTC, anonymous wrote:
> rust does it just fine without slicing, and supports both static dispatch and dynamic dispatch through the same interface.
>
> http://blog.rust-lang.org/2015/05/11/traits.html
>
> honestly, this is one of the worst parts of D. Being forced to code a certain way because it might be misused is the equivalent of digital socialism.

Everything is new does not have time to enter the weight of C++ and obsolete! This is the phenomenon of the digital socialism. Even D3 will not be able to correct this situation :)
Need to invent D++ to change the situation :)
Although you can just move forward and not to look at any Rusts.

On 05/15/2015 09:44 PM, Jonathan M Davis wrote:
> On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
>> Many STL types inherit from base classes, yet they are used as value
>> types: std::string, std::vector etc. Are there plans to support C++
>> types with inheritance as proper value types in D frontend?
>
> Given that the inheritance they have is actually undesirable when they
> are treated as value types, I doubt that there's much need. If you're
> using inheritance in C++, you're putting your class on the heap and
> accessing it via pointers,> in which case, accessing them in D as classes
> makes sense. And if you're using these STL types as value types on the
> stack, then they can be treated as value types. Doing otherwise just
> risks object slicing, which is not desirable in the least.
>
> So, while I don't know how we're going to be handling STL types (I don't
> even know what the current state of C++ state support is, since it keeps
> improving), I really don't see why there's value in supported
> inheritance with value types. It would just be begging for bugs - which
> is why native D types don't support it.
>
> - Jonathan M Davis

He didn't ask about support for object slicing, just support for proper interfacing to value types that happen to use implementation inheritance.


  template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>
    {


vector is a value type. You won't accidentally slice it, as the parent class is not accessible. _Vector_base is there to make exception safety easier AFAIK. It's basically an implementation detail. (Does anyone know why they are using protected inheritance instead of private inheritance?)

On Friday, 15 May 2015 at 21:11:48 UTC, Timon Gehr wrote:
> On 05/15/2015 09:44 PM, Jonathan M Davis wrote:
>> On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
>>> Many STL types inherit from base classes, yet they are used as value
>>> types: std::string, std::vector etc. Are there plans to support C++
>>> types with inheritance as proper value types in D frontend?
>>
>> Given that the inheritance they have is actually undesirable when they
>> are treated as value types, I doubt that there's much need. If you're
>> using inheritance in C++, you're putting your class on the heap and
>> accessing it via pointers,> in which case, accessing them in D as classes
>> makes sense. And if you're using these STL types as value types on the
>> stack, then they can be treated as value types. Doing otherwise just
>> risks object slicing, which is not desirable in the least.
>>
>> So, while I don't know how we're going to be handling STL types (I don't
>> even know what the current state of C++ state support is, since it keeps
>> improving), I really don't see why there's value in supported
>> inheritance with value types. It would just be begging for bugs - which
>> is why native D types don't support it.
>>
>> - Jonathan M Davis
>
> He didn't ask about support for object slicing, just support for proper interfacing to value types that happen to use implementation inheritance.
>
>
>   template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
>     class vector : protected _Vector_base<_Tp, _Alloc>
>     {
>
>
> vector is a value type. You won't accidentally slice it, as the parent class is not accessible. _Vector_base is there to make exception safety easier AFAIK. It's basically an implementation detail. (Does anyone know why they are using protected inheritance instead of private inheritance?)

If all you're looking to do is use an STL type as a value type, then in principle, a D struct should be able to be used for it just fine. I really don't see how the fact that it inherits from another class in C++ matters, since you can't use polymorphism if it's a value type. Worst case, you'd have to declare all of the base class functions as being part of the derived type, since they'll never be used as virtual functions when you're not dealing with C++ pointers. The only question is if the C++ compat stuff for D is able to handle a class which is a value type. And that, I don't know. The initial C++ compat stuff was built around interfaces, so it couldn't treat C++ classes as value types, and it couldn't deal with construction or destruction - just calling virtual functions. So, clearly, it didn't work previously, but I don't know what the C++ compat layer is currently capable of or what the technical issues would be in supporting a user-defined value type via the C++ compat layer. So, it wouldn't surprise me if we're able to do it at some point even if we can't do it now.

But regardless, I don't see how the C++ class having a base class in C++ would really matter when interfacing with D if the class is a value type.

- Jonathan M Davis

On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote:
> So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it.

I'm talking about support for C++ idioms in frontend code, so satisfactory interfacing with C++ can be done, native D types can stay as they are.

C++ value types are designed to be used as value types and usually provide automatic memory management via RAII and scoped destruction. Without RAII you have a more serious risk of resource leaks or code cluttered with delete operators, also using value types as D classes results in non-idiomatic code resembling more Java than D or C++, which can alienate C++ programmers and is confusing overall. See an example of such code: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d

Inheritance in C++ is not always for polymorphism, often it's just functionality inheritance, so if needed slicing can be prevented by preventing upcasts.

On Saturday, 16 May 2015 at 08:53:00 UTC, Jonathan M Davis wrote:
> But regardless, I don't see how the C++ class having a base class in C++ would really matter when interfacing with D if the class is a value type.

Currently D frontend can't use such idiom: it has classes, which support inheritance, but are reference types, it also has structs, which don't support inheritance and are value types, and they don't mix.

On Saturday, 16 May 2015 at 09:20:37 UTC, Kagamin wrote:
> Currently D frontend can't use such idiom: it has classes, which support inheritance, but are reference types, it also has structs, which don't support inheritance and are value types, and they don't mix.

In this case inheritance is just a code/structure sharing tool. D has mixins and alias this to do that.