Why can't structs be derived from?

[Jens]

Daniel Gibson wrote:
> Am 15.03.2011 21:07, schrieb Jens:
>> Daniel Gibson wrote:
>>> Am 15.03.2011 20:40, schrieb Jens:
>>>> Daniel Gibson wrote:
>>>>> Am 15.03.2011 20:24, schrieb Jens:
>>>>>> Daniel Gibson wrote:
>>>>>>> Am 15.03.2011 19:48, schrieb Jens:
>>>>>>>> Andrei Alexandrescu wrote:
>>>>>>>>> On 3/15/11 12:55 PM, Jens wrote:
>>>>>>>>>> Steven Schveighoffer wrote:
>>>>>>>>>>> That's all there is.  Structs do not have inheritance, only
>>>>>>>>>>> alias this.
>>>>>>>>>>
>>>>>>>>>> Why don't they though? Inheritance does not have to mean
>>>>>>>>>> polymorphic. It can mean composition, like in C++. I don't
>>>>>>>>>> understand the reason for such ugly syntax.
>>>>>>>>>
>>>>>>>>> Using inheritance for composition is frowned upon in C++ for
>>>>>>>>> good reasons. If you want composition, the best is to use
>>>>>>>>> composition.
>>>>>>>>
>>>>>>>> It was frowned upon early on because the compiler implementers
>>>>>>>> didn't have their acts together and the resulting objects
>>>>>>>> layout could not be relied upon. The example I gave came from
>>>>>>>> the STL so I think "frowned upon" is something you are picking
>>>>>>>> up from long ago.
>>>>>>>>
>>>>>>>> Composition means access through the members rather than direct
>>>>>>>> access:
>>>>>>>>
>>>>>>>> struct point
>>>>>>>> {
>>>>>>>>     int x;
>>>>>>>>     int y;
>>>>>>>> };
>>>>>>>>
>>>>>>>> struct point3d
>>>>>>>> {
>>>>>>>>     point pt;
>>>>>>>>     int z;
>>>>>>>> };
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> point3d mypoint;
>>>>>>>> mypoint.pt.x = 3; // ugly
>>>>>>>>
>>>>>>>
>>>>>>> This is why you add "alias pt this;" to point3d. So you can
>>>>>>>  write mypoint.x = 3;
>>>>>>>
>>>>>>
>>>>>> Still ugly though.
>>>>>>
>>>>>
>>>>> I don't think so. It makes obvious what happens: a composition -
>>>>> *not* an inheritance - with syntactic sugar that allows one to
>>>>> omit the .pt in mypoint.(pt.)x - as long as mypoint doesn't have
>>>>> a member x itself.
>>>>>
>>>>
>>>> YMMV. To me it's ugly enough to not take the language seriously.
>>>>
>>>>> Allowing inheritance syntax on structs would only lead to
>>>>> confusion - especially for people coming from C++.
>>>>>
>>>>
>>>> C++ does it that way, so what confusion are you talking about?
>>>>
>>>
>>> The confusion that in C++ classes and structs are basically the same
>>> (only the default visibility of members is different) while in D
>>> they're not.
>>> So allowing "inheritance" on structs would give the false impression
>>> that structs in D are also classes of some kind.
>>
>> Not a good reason to change the syntax. That's what the manual is
>> for. What you said was: "Someone is going to try to program in D
>> without reading the manual and then be surprised when it doesn't
>> work like C++ so we'll just remove the construct so that doesn't
>> happen -- at the expense of elegant syntax".
>>
>>>
>>> Furthermore I find C++'s class handling quite unfortunate..
>>
>> Me too, some of it.
>>
>>> only
>>> having polymorphism when explicitly using pointers really sucks.
>>
>> How is it different in D where all polymorphic objects are reference
>> types? Take have the design space away, make everything a glorified
>> pointer and things are better?
>
> They obviously are. Successful languages like Java and C# do it. It's
> less error-prone and you don't have to worry about dereferencing
> stuff all the time (sometimes even multiple dereferences at once,
> like in my example).

More toward Java-class-language then than C++-level language. Sacrificing 
stack objects was like throwing out sharp knives from the kitchen. I 
understand.