Any plans to support STL value types?

[Jonathan M Davis via Digitalmars-d]

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