Why can't structs be derived from?

[Jens]

Andrei Alexandrescu wrote:
> On 3/15/11 1:54 PM, Jens wrote:
>> Jesse Phillips wrote:
>>> Jens Wrote:
>>>
>>>> OK, silly me. I used a wrong example. I really did want to know
>>>> about non-polymorphic composition from structs via derivation.
>>>> Sorry for the confusion.
>>>>
>>>> struct point
>>>> {
>>>>      int x;
>>>>      int y;
>>>> };
>>>>
>>>> struct point3d: point
>>>> {
>>>>      int z;
>>>> };
>>>
>>> You already got your answer 'alias this' which you have dismissed as
>>> ugly. You wanted composition and I think it provides a very clean
>>> way to describe composition, especially since it looks nothing like
>>> how inheritance of classes which have polymorphic behavior.
>>
>> Inheritance and polymorphic behavior can be (should be IMO)
>> orthogonal.
>
> In concept it's easy to abide to strong stances, and I wouldn't
> disagree it's not half a bad thing. However, real-world issues do
> arise.

And all those xxx-ability words apply. Such as useability, 
comprehensibility, learnability.. etc. There is technical "correctness" 
and then there is "the good thing".

>
> Inheritance is often a desirable mechanism for implementing dynamic
> polymorphism for two main reasons. One, it prevents accidental
> polymorphism from happening. Two, it allows the compiler to lay out
> objects efficiently and make function invocation relatively fast
> without a need for global information. Offhand I don't think there
> are other reasons.
>
> Inheritance without polymorphism is technically possible, but rarely
> of any practical interest.

Yeah, jettison clean syntax because it's of little importance. :/

> In C++, next to nobody uses private
> inheritance systematically, and nobody really understands what
> protected inheritance really is.
>

I avoid private inheritance and never used protected inheritance. I use 
composition in those cases but that is when B. Meyer's books come of the 
shelf for a reread. I was originally talking just about structural 
extension (I probably said "composition" but "extension" is a tad better 
term) via inheritance syntax. "inheritance" isn't the key thought in all 
of that. "extension" and "syntax" are.

> Polymorphism without inheritance is the election mechanism during
> compilation, and possible for runtime polymorphism with
> well-understood reflection mechanisms (btw I see now that adaptTo has
> not been yet added to std.typecons...)
>
> All in all inheritance is strongly associated with polymorphism as it
> is a basic mechanism for implementing it, so it would be tenuous to
> force the two to be orthogonal.

"orthogonal" is a bit strong, but I left it in. Let's face it, when you 
derive, you get data members and methods. In a struct with no methods, 
you get data members only, in a nice clean way. I find that compelling, 
syntax-wise.

>
>>> Also note the
>>> intent is to allow for multiple 'alias this' declarations, but
>>> hasn't yet been implemented.
>>>
>>> struct point
>>> {
>>>      int x;
>>>      int y;
>>> };
>>>
>>> struct point3d
>>> {
>>>      point p; // I own a point
>>>      alias this p;  // I am a composition of a point p.
>>>      int z;
>>> };
>>
>> I didn't ask how to do composition in D. I asked why composition
>> cannot be done via derivation, i.e., the reasoning behind the
>> language design choice. A design faux paus IMO.
>
> I would agree, with the slight amendment that this time for once the
> faux pas is in the design of the application, not that of the
> language.

We'll have to agree to disagree on this one then. I'm sure there will be 
others. ;)