Why can't structs be derived from?

[Jens]

Andrei Alexandrescu wrote:
> 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.

The concept begs for a non-keyword-within-the-struct syntax, IMO. That 
you don't mind looking at it is fine. I can't stand it.

>>>> 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?
>

Walter or you or whoever screwed that one up.

>>> 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?

I meant using D.

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

I don't know what you mean. Or what part did you not understand?

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

Are you over-emphasizing "the slicing problem" to justify D's solution to 
it?