Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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.
templatetypename _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
Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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
Re: Any plans to support STL value types?
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
Re: Any plans to support STL value types?
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
Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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.
Re: Any plans to support STL value types?
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.
Any plans to support STL value types?
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?
Re: Any plans to support STL value types?
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.
templatetypename _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?)
