www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any plans to support STL value types?

reply "Kagamin" <spam here.lot> writes:
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?
May 15 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 15 2015
next sibling parent reply "anonymous" <anonymous anonymail.com> writes:
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.
May 15 2015
next sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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.
May 15 2015
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 15 May 2015 at 19:51:09 UTC, anonymous wrote:
 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.
How is this a "digital socialism"? :) Nobody forces you anything. The community made Phobos - if you do not like it, use something else. :) There is Tango/D2 project too, if that one does not fit your need, use OR create something else! Second, what do you mean when you say (type) "D"? D community, D programming language, or what? If by D you refer to D as a programming language (and that is what I think when you say D) - sorry to break it up to you, but EVERY SINGLE language (not just programming) forces specific rules upon programmer! Back to the topic - nobody stops anyone from writing a module which provides what the original question was about. Is there any value in having STL value types? - I do not see them, but that does not mean someone else may see it differently.
May 19 2015
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 19 May 2015 at 12:46:50 UTC, Dejan Lekic wrote:
 Is there any value in having STL value types?
More natural and safe C++ interfacing instead of some bug-prone hybrid, which is neither D nor C++ and is even more horrible than C++ itself.
May 19 2015
prev sibling next sibling parent "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
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.
May 15 2015
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?)
May 15 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 16 2015
parent reply "Kagamin" <spam here.lot> writes:
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.
May 16 2015
parent reply "QAston" <qastonx gmail.com> writes:
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.
May 16 2015
parent "lobo" <swamplobo gmail.com> writes:
On Saturday, 16 May 2015 at 12:22:00 UTC, QAston wrote:
 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.
This is what I currently use now for composition of structs where I'd consider using private inheritance in C++. The semantics are not identical of course, e.g. construction and initialization differ for one, but it works very well in my situation. bye, lobo
May 16 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
May 16 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 16 May 2015 at 09:11:46 UTC, Kagamin wrote:
 Inheritance in C++ is not always for polymorphism, often it's 
 just functionality inheritance
Exactly, so if D support C++ classes as value types, they'd just be declared as structs in D and no inheritance would be required. Any functions that existed in a based class could simply be declared as being part of the derived class in the D version. There is no need for D to know or care that the C++ type is implemented via inheritance, because polymorphism isn't applicable. Now, obviously, support would be needed for D to understand C++ types well enough to have D structs which correspond with C++ classes which are value types, and AFAIK, we don't currently have that, but I really don't see why the inheritance factor matters. The base class members or functions are simply additional members of the derived class as far as D would be concerned, because you'd never convert to the base type. The problem in actually implementing support for it in D is likely going to stem from the fact that support for matching the C++ memory layout would have to be there as well as matching the construction and destruction semantics of C++. And that being the case, I expect that it's most likely that support would exist via some kind of conversion at the point where C++ and D meet rather than truly supporting the C++ value types in D code, but we'll just have to wait and see. It's a nasty problem. And we already support way better C++ integration than is typically done in other languages. Usually, C integration is as far as it goes. - Jonathan M Davis
May 16 2015
parent "w0rp" <devw0rp gmail.com> writes:
JMD is right. Using inheritance for value types is a bad idea, 
and it shouldn't be done.

The problem is that when you assign a derived value type to a 
base value type, the members in the derived type are removed, and 
this can lead to very weird behaviour. You could enforce that 
derived value types can never add any members, but then what 
would be the point? For adding virtual method calls for changing 
behaviour?

Using inheritance for reference types only was one of the better 
design decisions for D. If you want to treat a set of structs in 
a similar way, you can do it better with parametric polymorphism 
than with classes and virtual method calls.
May 19 2015