Can we just have struct inheritence already?

[XavierAP]

On Tuesday, 18 June 2019 at 18:39:41 UTC, Olivier FAURE wrote:
> On Tuesday, 18 June 2019 at 12:17:36 UTC, Manu wrote:
>>
>> alias this *should* be a very niche feature, but instead we 
>> abuse it
>> in lieu of struct inheritance, and no way to perform implicit
>> conversion. In both cases it's a gross code smell, and I hate 
>> it.
>
> It might be because I write a lot less generic code than you 
> do, but I really don't understand why you lend so much 
> importance to implicit conversion.
>
> XavierAP's question is particularly relevant here:
>
>> What is the benefit of
>>
>> 	struct A { void fun(); }
>> 	struct B :A {}
>>
>> 	B b;
>> 	b.fun;
>>
>> compared to
>>
>> 	struct A {}
>> 	struct B { A a; }
>>
>> 	B b;
>> 	b.a.fun;
>>
>
> Like, seriously, I might be missing something, but I don't get 
> it.
>
> Can you cite some use case where inheritance is convenient but 
> composition isn't? Ideally an actual use case that came up in a 
> project?

I'm not against struct inheritance... Even though I don't get or 
haven't looked into Manu's application, and I rather try to 
understand the pros and cons in general, my impression is that he 
knows what he's talking about and has likely considered plenty of 
implications elsewhere, but he's tired of discussing over again. 
:p

In very general terms there are potential risks when things 
happen implicitly. A new feature with such effects is likelier to 
have unintended consequences at least in corner cases. That's 
where my questions were coming from.

But my initial guess is that there might be nothing wrong with 
struct inheritance, at least if the value semantics are 
preserved. And I do agree with Manu that alias this should be a 
very niche feature, and we are using it for structs as clumsier, 
dirtier and more verbose way to get the regular (static) 
polymorphism that we'd better implement by inheritance if 
possible.

Walter himself has admitted (in the multiple alias this thread) 
that alias this can be equivalent to inheritance (and that's 
argument enough why multiple's bad).

Something else in these discussions, the current fashion in CS is 
that inheritance is bad and you should use composition instead 
every single time -- just like the past OOP fad said the opposite 
against C. I agree that too deep or extensive inheritance 
hierarchies are a bad pattern, but inheritance isn't bad in 
itself or in moderation.

And again this discussion gets mixed up with C++ people who 
design classes inheriting from the STL. Since it's probably a bad 
idea to extend a library following the opposite architecture 
patterns and design intent of the library, it's probably a bad 
idea to inherit from the STL (and the lack of virtual 
constructors doesn't help), but this get mixed up with the idea 
that inheriting itself would be always a bad idea for any 
architecture. And the fact that the STL was not made with an 
(even non virtual) inheritance architecture (*ahem* 
std::basic_string *ahem*) also makes inheritance less popular -- 
nowadays in comparison with composition, even though STL uses 
templates not composition.