biozic Wrote:

> Le 29/01/11 14:43, Jim a écrit :
> > I'm a bit troubled with the class/struct dichotomy. I would prefer them both to use the same keyword. Heap/stack allocation could be specified during instantiation instead. Why? Now you need to choose one over the other. Not even C++ has this limitation.
> >
> > Think about containers for example, should they be classes or structs? Do you want them on the stack or on the heap?
> >
> > I guess it's possible to define the entire container as a mixin now. That would let you have both heap and stack containers share definition, but generally I think that the dichotomy should be abolished.
> 
> The difference between class and struct in D is more than heap or stack allocation. Having a common keyword for them would unwisely mask their fundamental differences (inheritance/polymorphism, reference/value semantics, etc.).
> 
> Perhaps the suggestion is in fact one that has already been made but for which I can't remember the conclusion: how about abandoning 'new' in favor of more specific keywords/library templates that control whether the instantiation occur on the heap or on the stack?


Yes, abandoning new if it would help. Objects on the heap could be managed by different garbage collectors (or with different settings, mark-sweep, precise/conservative, reference-counting, etc.).

I don't want to have to change the definition of the type. The instantiation is a separate concern to the implementation. It should be up to the user of a type to decide whether to allocate it on the stack or the heap and so on.

The compiler should be intelligent enough to see whether the class is derived or not and do its optmisations accordingly.

On Saturday 29 January 2011 07:11:41 Jim wrote:
> biozic Wrote:
> > Le 29/01/11 14:43, Jim a écrit :
> > > I'm a bit troubled with the class/struct dichotomy. I would prefer them both to use the same keyword. Heap/stack allocation could be specified during instantiation instead. Why? Now you need to choose one over the other. Not even C++ has this limitation.
> > > 
> > > Think about containers for example, should they be classes or structs? Do you want them on the stack or on the heap?
> > > 
> > > I guess it's possible to define the entire container as a mixin now. That would let you have both heap and stack containers share definition, but generally I think that the dichotomy should be abolished.
> > 
> > The difference between class and struct in D is more than heap or stack allocation. Having a common keyword for them would unwisely mask their fundamental differences (inheritance/polymorphism, reference/value semantics, etc.).
> > 
> > Perhaps the suggestion is in fact one that has already been made but for which I can't remember the conclusion: how about abandoning 'new' in favor of more specific keywords/library templates that control whether the instantiation occur on the heap or on the stack?
> 
> Yes, abandoning new if it would help. Objects on the heap could be managed by different garbage collectors (or with different settings, mark-sweep, precise/conservative, reference-counting, etc.).
> 
> I don't want to have to change the definition of the type. The instantiation is a separate concern to the implementation. It should be up to the user of a type to decide whether to allocate it on the stack or the heap and so on.
> 
> The compiler should be intelligent enough to see whether the class is derived or not and do its optmisations accordingly.

structs are value types. classes are reference types. That can drastically change how they are designed and used. Passing something to

void func(A a) {/*...*/}

is going to have _vastly_ different behavior when dealing with value types than when dealing with reference types. For a value type, it'll be a copy. For a reference type, it's just copying the reference, so the function is free to change the state of the object that you passed in. How on earth would the compiler decide which behavior is correct? It can't. That's up to the programmer.

The differences between structs and classes are critical. It's _not_ just a question of optimization. And the compiler can't generally make an optimization choice based on whether a type is derived or not anyway, because it also needs to know whether a type is derivide from _it_, and it can't know that at compile time thanks to the separate compilation model. Classes don't know about what types are derived from them, and the derived types could be in entirely separate libraries - separate shared libraries even (assuming that shared libraries are properly supported, which is on the TODO list).

C# also chose to make structs and classes separate. It's a solide design decision. In many, many cases, how a classes is designed and functions is affected by how it is instantiated. It can make a big difference whether a type is intended to be instantiated on the stack or on the heap.

structs are value types without inheritance or polymorphism. They support RAII.

classes are reference types with inheritance and polymorphism. They don't really support RAII (they have destructors, but there's no guarantee that they'll ever be called, and there are various limitation on their destructors).

They are distinctly different. It was a mistake for C++ to have polymorphic types which could go on the stack. It causes slicing and ultimately doesn't make sense. If you program in C++, you learn to deal with it and program in a way that it doesn't cause problems, but it's still a problematic design choice. Separating user-defined value and reference types makes things considerably cleaner and safer. C# did and and D does it. Java didn't do it, but that's because it doesn't _have_ user-defined value types. C++ is the only language that I know of which tries to conflate user-defined value and reference types.

It may take some getting used to, but D's choice of separating structs and classes is a solid one.

- Jonathan M davis