Why can't structs be derived from?

[Daniel Gibson]

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).

> 
>> e.g. you have a base class Foo and a class Bar derived from Foo.. now
>> you wanna put Objects of type Foo and Bar in a list.. what do you do?
> 
> We'll have to save container design for another day.
>