digitalmars.D - Any plans to support STL value types?
- Kagamin (4/4) May 15 2015 Many STL types inherit from base classes, yet they are used as
- Jonathan M Davis (15/19) May 15 2015 Given that the inheritance they have is actually undesirable when
- anonymous (7/27) May 15 2015 rust does it just fine without slicing, and supports both static
- Dennis Ritchie (6/12) May 15 2015 Everything is new does not have time to enter the weight of C++
- Dejan Lekic (14/44) May 19 2015 How is this a "digital socialism"? :) Nobody forces you anything.
- Kagamin (4/5) May 19 2015 More natural and safe C++ interfacing instead of some bug-prone
- Laeeth Isharc (5/25) May 15 2015 Is there any place better to go to learn about C++ support than
- Timon Gehr (10/27) May 15 2015 He didn't ask about support for object slicing, just support for proper
- Jonathan M Davis (22/65) May 16 2015 If all you're looking to do is use an STL type as a value type,
- Kagamin (16/22) May 16 2015 I'm talking about support for C++ idioms in frontend code, so
- Jonathan M Davis (26/28) May 16 2015 Exactly, so if D support C++ classes as value types, they'd just
- w0rp (12/12) May 19 2015 JMD is right. Using inheritance for value types is a bad idea,
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
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
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: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.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
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
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: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.On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin 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.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 19 2015
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
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: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.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
On 05/15/2015 09:44 PM, Jonathan M Davis wrote:On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: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?)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
On Friday, 15 May 2015 at 21:11:48 UTC, Timon Gehr wrote:On 05/15/2015 09:44 PM, Jonathan M Davis wrote: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 DavisOn Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: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?)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 16 2015
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
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
On Saturday, 16 May 2015 at 12:22:00 UTC, QAston wrote:On Saturday, 16 May 2015 at 09:20:37 UTC, Kagamin wrote: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, loboCurrently 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
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
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 inheritanceExactly, 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
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