On Sunday, June 9, 2019 2:05:34 AM MDT Manu via Digitalmars-d wrote:
> I am really really tired of this pattern:
>
> struct DerivedStruct
> {
>     static if (BaseStruct.tupleof.length > 0)
>         BaseStruct base;
>     else
>         ref inout(BaseStruct) base() inout { return
> *cast(inout(BaseStruct)*)&this; }
>     alias base this;
>
>     // derived members
>     //...
> }
>
> Imagine if we could just write:
>
> struct DerivedStruct : BaseStruct
> {
>     // derived members
>     //...
> }
>
> Just imagine!

I've never even seen code use such a pattern before, and honestly, it seems really weird to me to even write code that acts like one struct is derived from another, because without polymorphism, I wouldn't really have thought that that would make any sense.

However, if you're using this pattern frequently, what's stopping you from just creating a function or template to use with mixin that takes care of it for you? I would have thought that it would be fairly straightforward to do something like

struct DerivedStruct
{
    mixin(aliasAsMember!BaseStruct);
}

and then it really isn't any more complex than

struct DerivedStruct : BaseStruct
{
}

would be.

- Jonathan M Davis

On Sunday, 9 June 2019 at 13:59:25 UTC, Jonathan M Davis wrote:
> I've never even seen code use such a pattern before, and honestly, it seems really weird to me to even write code that acts like one struct is derived from another, because without polymorphism, I wouldn't really have thought that that would make any sense.
>
> struct DerivedStruct
> {
>     mixin(aliasAsMember!BaseStruct);
> }
>
such construct says "like-a" for me.
its some difficult workaround of
> struct DerivedStruct : BaseStruct
> {
> }
>
clear and explicitly says "is-a" for me

Point3D is a Point2D plus z, not Point3D like a Point2D with z. maybe for u this is same mean.

The point(another mean) lays in human habits, all of us know C++, we expecting clear and obvious things. The point is not that which is more correct, but that it is more familiar, what is expected.
Same for double.init=NaN - maybe its right in some view, but all langs that I know initialize globals with zeroes. I expecting zeroes. I expecting "using noninitalized variable" when I do something d+=.. with such var not the NaN.
When u have a deal with known things u do less errors and typos than when u fight with unexpected "right way".

On Sunday, 9 June 2019 at 15:02:29 UTC, KnightMare wrote:
>> struct DerivedStruct : BaseStruct
and this need just one colon

On Sunday, 9 June 2019 at 15:13:06 UTC, KnightMare wrote:
> On Sunday, 9 June 2019 at 15:02:29 UTC, KnightMare wrote:
>>> struct DerivedStruct : BaseStruct
> and this need just one colon

but alias useful too when u want to use struct like another type without cast or calling method. for example
decimal dec;
funcThatExpectDouble( dec); // instead dec.toDouble()
// I prefer implicit opCast that is absent too

On Sunday, 9 June 2019 at 15:02:29 UTC, KnightMare wrote:
> On Sunday, 9 June 2019 at 13:59:25 UTC, Jonathan M Davis wrote:
>> I've never even seen code use such a pattern before, and honestly, it seems really weird to me to even write code that acts like one struct is derived from another, because without polymorphism, I wouldn't really have thought that that would make any sense.
>>
>> struct DerivedStruct
>> {
>>     mixin(aliasAsMember!BaseStruct);
>> }
>>
> such construct says "like-a" for me.
> its some difficult workaround of
>> struct DerivedStruct : BaseStruct
>> {
>> }
>>
> clear and explicitly says "is-a" for me
>
> Point3D is a Point2D plus z, not Point3D like a Point2D with z. maybe for u this is same mean.
>
> The point(another mean) lays in human habits, all of us know C++, we expecting clear and obvious things. The point is not that which is more correct, but that it is more familiar, what is expected.
> Same for double.init=NaN - maybe its right in some view, but all langs that I know initialize globals with zeroes. I expecting zeroes. I expecting "using noninitalized variable" when I do something d+=.. with such var not the NaN.
> When u have a deal with known things u do less errors and typos than when u fight with unexpected "right way".

Don't think I've seen a Point3D ever use inheritance to with a Point3D. Basically all the functions will need to be reimplemented. And some don't even make sense to reimplement because they only apply to 2d.

You can also make a 2D point from each axis, xy, xz, yz, and you can switch those around etc.

On Sunday, 9 June 2019 at 13:59:25 UTC, Jonathan M Davis wrote:
> I've never even seen code use such a pattern before, and honestly, it seems really weird to me to even write code that acts like one struct is derived from another, because without polymorphism, I wouldn't really have thought that that would make any sense.

It is very common. If you want to model events as value types for instance.

It is common even in C, implemented as unions with reinterpretation casts. Most large frameworks do this in one way or another. Random example: X-Windows.

On Sun, Jun 9, 2019 at 6:59 AM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, June 9, 2019 2:05:34 AM MDT Manu via Digitalmars-d wrote:
> > I am really really tired of this pattern:
> >
> > struct DerivedStruct
> > {
> >     static if (BaseStruct.tupleof.length > 0)
> >         BaseStruct base;
> >     else
> >         ref inout(BaseStruct) base() inout { return
> > *cast(inout(BaseStruct)*)&this; }
> >     alias base this;
> >
> >     // derived members
> >     //...
> > }
> >
> > Imagine if we could just write:
> >
> > struct DerivedStruct : BaseStruct
> > {
> >     // derived members
> >     //...
> > }
> >
> > Just imagine!
>
> I've never even seen code use such a pattern before,

I've been doing this for 10 years, and I'd rank it up there with 'ref' in terms of annoying weird shit.

> and honestly, it seems
> really weird to me to even write code that acts like one struct is derived
> from another, because without polymorphism, I wouldn't really have thought
> that that would make any sense.

Woah, that's a weird logical leap! Why would you or anyone expect a
struct to be polymorphic now? It's not heap allocated, and has no
vtable or virtual, or final, or any of those things.
You've gotta really reach to make that conclusion, and the compiler
will produce errors informing you every step of the way.

> However, if you're using this pattern frequently, what's stopping you from just creating a function or template to use with mixin that takes care of it for you? I would have thought that it would be fairly straightforward to do something like
>
> struct DerivedStruct
> {
>     mixin(aliasAsMember!BaseStruct);
> }
>
> and then it really isn't any more complex than
>
> struct DerivedStruct : BaseStruct
> {
> }
>
> would be.

Classic response.

Because:
1, that sucks!
2, DRY; some structs have common elements. (how can anyone find that
surprising?) I don't want to repeat them all over the place!
3, syntax highlighting breaks from that point down !!!
4, debuginfo breaks from that point down !!!
5, debugging experience is embarrassing !!!
6, it depends on naming conventions (of the base object/function),
which are brittle
7, meta to determine the base type is problematic and very complex if
it wants to be accurate
8, did i mention it just plain sucks!

This is NOT polymorphism, we're not talking about polymorphism, I wish people would not change the topic.

On Sunday, 9 June 2019 at 21:13:50 UTC, Manu wrote:
> This is NOT polymorphism, we're not talking about polymorphism, I wish people would not change the topic.

Well, it sort of is. Consider a situation where you have assignment defined for the super class, and where there is a field in the subclass that depends on a field in super.

On Sunday, 9 June 2019 at 21:35:19 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 9 June 2019 at 21:13:50 UTC, Manu wrote:
>> This is NOT polymorphism, we're not talking about polymorphism, I wish people would not change the topic.
>
> Well, it sort of is. Consider a situation where you have assignment defined for the super class, and where there is a field in the subclass that depends on a field in super.

Or rather: you sometimes have a dependency, then you want the type system to prevent assignments through the base class. However, in other cases you don't have a dependency, then you do want to be able to assign through the base class.

But you need something syntactical to tell the type system that such dependencies exist.

On Sun, Jun 9, 2019 at 2:40 PM Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 9 June 2019 at 21:13:50 UTC, Manu wrote:
> > This is NOT polymorphism, we're not talking about polymorphism, I wish people would not change the topic.
>
> Well, it sort of is. Consider a situation where you have assignment defined for the super class, and where there is a field in the subclass that depends on a field in super.

I can form a misuse fail for practically any language feature. It's possible we identify some common-sense restrictions here to inhibit the worst of them, but the current restriction is anti-productive, the line in the sand is drawn incorrectly.

For contrast, I've been arguing on bug reports recently that people
think interactions with uninitialised unions (or =void initialised
code) is @safe... 🤯🤯🤯
which just shows how astonishingly arbitrary this shit is.