Why can't structs be derived from?

[Andrei Alexandrescu]

On 3/15/11 2:07 PM, Jens wrote:
> Andrei Alexandrescu wrote:
>> STL's mild abuses of inheritance (in the absence of something better
>> such as aliases) are known and understood without being condoned at
>> large. For a good account of why composition is preferable to
>> inheritance, you may want to refer to
>> http://www.artima.com/cppsource/codestandards3.html and the referred
>> bibliography.
>>
>
> Knowing where to break from "absolutisms" is important. There's nothing
> wrong with doing extension of structs via derivation.

With amendments (data protection, lvalue vs. rvalue access, hooks upon 
conversion to base...), sure. That's why we included alias this as a 
mechanism that encompasses such functionality (including user-controlled 
conversions) without adding one language feature for each.

>>> 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
>>>
>>>>
>>>> The reason for the allegedly ugly syntax is that it's considerably
>>>> more general.
>>>
>>> Over-generality is a key thing that gets languages in trouble.
>>
>> This is general enough to be too vacuous.
>
> It is easily observable. Knowing where to draw the lines is key. In this
> instance, I think he blew it.

He being whom?

>> We figured we need a better
>> subtyping mechanism for structs and designed 'alias this' for that
>> purpose. How is this getting D in trouble?
>
> I won't use it.

How is you not using 'alias this' is getting D in trouble?

>>>> It is often the case that a struct defines an entity
>>>> that is implicitly convertible to another entity - could be an
>>>> rvalue vs. lvalue, a class vs. another struct vs. a primitive type,
>>>> could need a run-time operation etc. Inheritance would offer at
>>>> best few of these amenities, whereas 'alias this' offers all with a
>>>> simple syntax.
>>>
>>> What's wrong with conversion operators? I wouldn't use "simple" and
>>> "ugly" in the same sentence. I would have chosen a different design.
>>
>> Please give detail on the design you would have chosen, thanks.
>>
>
> I have no problem with a C++-like way. I think it needed not been
> drastically departed from. I have an object model planned but I'm not
> about to detail it here. Sometimes I wonder if D has the goal of changing
> as much as possible just for change sake.

You'd have better success with substantiating that point using pretty 
much any other feature. This is a losing pick.

D was designed by people very familiar with C++, appreciative of its 
qualities, and aware of its issues. A cosmopolitan community also 
provided input to the design. Inadvertent C++ object slicing was 
considered (and for good reasons I think) a major issue in C++ that 
needed to be addressed. There would definitely be several ways of 
addressing it, but using sheer inheritance for polymorphic classes and 
'alias this' for monomorphic structs is a very robust combination.


Andrei