On Thursday, 20 December 2018 at 16:10:39 UTC, H. S. Teoh wrote:
> On Thu, Dec 20, 2018 at 03:44:34PM +0000, 12345swordy via Digitalmars-d wrote:
>> On Thursday, 20 December 2018 at 15:29:50 UTC, H. S. Teoh wrote:
>> > On Thu, Dec 20, 2018 at 12:15:53AM -0800, Manu via Digitalmars-d wrote:
>> > > [...]
>> > [...]
>> > > [...]
>> > [...]
>> > 
>> > Sigh... when is multiple alias this ever going to happen??
>> > 
>> > 
>> > T
>> 
>> When IgorStepanov quit disappearing on us. https://github.com/dlang/dmd/pull/8378
> [...]
>
> IIRC, that PR was blocked because of disagreements over how ambiguous symbols over multiple alias this types would be resolved.  Somebody needs to come up with a DIP with well-defined semantics for all the details and corner cases before this can move forward.
>
>
> T
Then DIP 66 have failed and needs to be rejected.

Alex

On Thu, Dec 20, 2018 at 04:45:13PM +0000, 12345swordy via Digitalmars-d wrote:
> On Thursday, 20 December 2018 at 16:10:39 UTC, H. S. Teoh wrote:
> > On Thu, Dec 20, 2018 at 03:44:34PM +0000, 12345swordy via Digitalmars-d wrote:
> > > On Thursday, 20 December 2018 at 15:29:50 UTC, H. S. Teoh wrote:
[...]
> > > > > Sigh... when is multiple alias this ever going to happen??
[...]
> > > When IgorStepanov quit disappearing on us. https://github.com/dlang/dmd/pull/8378
> > [...]
> > 
> > IIRC, that PR was blocked because of disagreements over how ambiguous symbols over multiple alias this types would be resolved. Somebody needs to come up with a DIP with well-defined semantics for all the details and corner cases before this can move forward.
[...]
> Then DIP 66 have failed and needs to be rejected.
[...]

Ahh, I thought you were pointing to dmd PR #3998, the original multiple alias this PR.  My bad.  I see that this is a newer PR submitted just earlier this year. I don't know if it addressed the concerns raised here:

	https://forum.dlang.org/post/m74pg8$gl4$1@digitalmars.com

which I assume would be required to pass scrutiny by W&A.  But in any case, there was some feedback but Igor seems to have gone MIA. Hopefully he shows up again soon.  I've been waiting for multiple alias this for years now. :-/


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan

On Thursday, 20 December 2018 at 18:04:12 UTC, H. S. Teoh wrote:
> On Thu, Dec 20, 2018 at 04:45:13PM +0000, 12345swordy via Digitalmars-d wrote:
>> On Thursday, 20 December 2018 at 16:10:39 UTC, H. S. Teoh wrote:
>> > On Thu, Dec 20, 2018 at 03:44:34PM +0000, 12345swordy via Digitalmars-d wrote:
>> > > On Thursday, 20 December 2018 at 15:29:50 UTC, H. S. Teoh wrote:
> [...]
>> > > > > [...]
> [...]
>> > > When IgorStepanov quit disappearing on us. https://github.com/dlang/dmd/pull/8378
>> > [...]
>> > 
>> > IIRC, that PR was blocked because of disagreements over how ambiguous symbols over multiple alias this types would be resolved. Somebody needs to come up with a DIP with well-defined semantics for all the details and corner cases before this can move forward.
> [...]
>> Then DIP 66 have failed and needs to be rejected.
> [...]
>
> Ahh, I thought you were pointing to dmd PR #3998, the original multiple alias this PR.  My bad.  I see that this is a newer PR submitted just earlier this year. I don't know if it addressed the concerns raised here:
>
> 	https://forum.dlang.org/post/m74pg8$gl4$1@digitalmars.com
>
> which I assume would be required to pass scrutiny by W&A.  But in any case, there was some feedback but Igor seems to have gone MIA. Hopefully he shows up again soon.  I've been waiting for multiple alias this for years now. :-/
>
>
> T

Do we have any means of contacting him? That seems like a job of the current PR manager Nicholas Wilson. FFS do we need a crowed funding to finished the damn thing? It been years already, and we can't rely on a single guy who keeps disappearing for long periods of time.

-Alex

On Thu, Dec 20, 2018 at 7:00 AM Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 12/20/18 3:15 AM, Manu wrote:
> > On Wed, Dec 19, 2018 at 7:45 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 12/19/2018 5:40 PM, Manu wrote:
> >>   > static if (Base.tupleof.length == 0)
> >>
> >> static if (Base.sizeof == 0)
> >
> > Empty struct has sizeof == 1 no? It certainly takes that many bytes as a member, and that 1 byte is naturally padded out to the alignment of the following member.
>
> Yes, it does take 1 byte. I believe the reasoning was so it could have a unique address and be used in an array.
>
> It's the same in C++ as well, according to the Internet (except for the base class optimization allowance). Note that C++ compilers aren't *required* to implement this.
>
> The difference between inheritance and manual inheritance (i.e. alias this and a member), is that with true inheritance there is no member that has to have it's own distinct address, so it's allowed to take up 0 space
>
> But I would expect your boilerplate could be handled via mixin template pretty easily, then it becomes:
>
> struct Derived
> {
>     mixin DeriveFrom!Base;
> }

Right, but that's still pretty shit, and I still don't know what
advantage it has? Now the pattern you have to look for to understand
you are dealing with a derived type is even more bespoke; every code
base will have a different expression for this, and people might do it
differently in different cases.
Every single person I've interacted with that's encountered D has been
surprised by this. I'm not sure there's a good reason for it.

I'm not saying the current method shouldn't exist, or that it's bad design or not useful. I'm just saying that BOTH should exist, and the syntax may just be sugar for simple, common, and expected aggregation. It can even call the member 'super', instead of some random name. `alias this` is great, but it's too manual, too much noise, and not searchable, which isn't great for the simple case which is deployed 99% of the time.

> That it takes up the one alias this slot is a bummer, but really we should implement multiple-alias-this and that problem would be solved.

That's been accepted for years now... why is there no movement? Is the features as defined incompatible with the implementation of DMD?

On Thu, Dec 20, 2018 at 06:13:28PM +0000, 12345swordy via Digitalmars-d wrote: [...]
> > Ahh, I thought you were pointing to dmd PR #3998, the original multiple alias this PR.  My bad.  I see that this is a newer PR submitted just earlier this year. I don't know if it addressed the concerns raised here:
> > 
> > 	https://forum.dlang.org/post/m74pg8$gl4$1@digitalmars.com
> > 
> > which I assume would be required to pass scrutiny by W&A.  But in any case, there was some feedback but Igor seems to have gone MIA. Hopefully he shows up again soon.  I've been waiting for multiple alias this for years now. :-/
[...]
> Do we have any means of contacting him? That seems like a job of the current PR manager Nicholas Wilson. FFS do we need a crowed funding to finished the damn thing? It been years already, and we can't rely on a single guy who keeps disappearing for long periods of time.
[...]

Maybe we should just crowdfund this thing.  It's been far too long, and there have been too many failed attempts at it.  Maybe past attempts were abandoned because it turned out to be far too much more work than was anticipated, and what it takes is somebody to get paid to dedicate their full time to slogging through all the tedious/complicated bits until it gets to the finish line.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

On Thu, Dec 20, 2018 at 10:20:54AM -0800, Manu via Digitalmars-d wrote:
> On Thu, Dec 20, 2018 at 7:00 AM Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
[...]
> > That it takes up the one alias this slot is a bummer, but really we should implement multiple-alias-this and that problem would be solved.
> 
> That's been accepted for years now... why is there no movement? Is the features as defined incompatible with the implementation of DMD?

There has been multiple attempts to implement it, but none were persistent enough to see it through to the finish line.

Maybe it's time to crowdfund a dedicated, full-time effort to bring this into a reality.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy

On Thu, Dec 20, 2018 at 8:10 AM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thu, Dec 20, 2018 at 03:44:34PM +0000, 12345swordy via Digitalmars-d wrote:
> > On Thursday, 20 December 2018 at 15:29:50 UTC, H. S. Teoh wrote:
> > > On Thu, Dec 20, 2018 at 12:15:53AM -0800, Manu via Digitalmars-d wrote:
> > > > On Wed, Dec 19, 2018 at 7:45 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > > [...]
> > > > > > Why should it be impossible to derive a struct?
> > > > >
> > > > > Because polymorphism makes little sense for a value type.
> > > >
> > > > It's not really polymorphism without a vtable, just simple extension. `alias this` produces the same result, it's just more wordy, kinda ugly, and boilerplate-ey. It also hogs the `alias this` slot.
> > > [...]
> > >
> > > Sigh... when is multiple alias this ever going to happen??
> > >
> > >
> > > T
> >
> > When IgorStepanov quit disappearing on us. https://github.com/dlang/dmd/pull/8378
> [...]
>
> IIRC, that PR was blocked because of disagreements over how ambiguous symbols over multiple alias this types would be resolved.  Somebody needs to come up with a DIP with well-defined semantics for all the details and corner cases before this can move forward.

Sounds like the original accepted DIP needs to be amended?

On 12/20/2018 12:15 AM, Manu wrote:
> Right, by necessity, because an empty struct member takes padded space
> in the aggregate.
> I think C++ gets the empty-base-class mechanic right; it doesn't take space.

It does take space in C++ depending on the compiler and the circumstance (it's rather complicated). D behaves like the associated C++ compiler in that regard - if it doesn't please file a bug report.

> I'm demonstrating crappy code that appears extremely frequently in lieu.
> Perhaps you have a better suggestion?
> 
>>> Why should it be impossible to derive a struct?
>>
>> Because polymorphism makes little sense for a value type.
> 
> It's not really polymorphism without a vtable, just simple extension.
> `alias this` produces the same result, it's just more wordy, kinda
> ugly, and boilerplate-ey.

It seems you have a workaround for what you want to do, and it's a simple paste job. You could probably accomplish the same thing with a mixin template.

> It also hogs the `alias this` slot.

C++ doesn't have alias this, so why would there be a slot for it?


>>   > static if (Base.tupleof.length == 0)
>>
>> static if (Base.sizeof == 0)
> 
> Empty struct has sizeof == 1 no? It certainly takes that many bytes as
> a member,

Not necessarily, see "empty base optimization". But you're right for this particular case.

https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Empty_Base_Optimization

On 12/20/2018 6:55 AM, Steven Schveighoffer wrote:
> really we should implement multiple-alias-this and that problem would be solved.

And create a host of other problems. Multiple alias this is multiple inheritance with all of C++'s problems with it, and more, because then you wind up with two (count 'em, 2!) multiple inheritance hierarchies. Madness. Even single alias this has spawned a fair amount of wreckage in bugzilla, because people use it for multiple inheritance which it was never intended for.

MI is just a bad idea. It's best to just think of another way to structure the data - even if you get it to work, it'll just confuse the poor schlub who has to maintain the code.

On Friday, 21 December 2018 at 03:04:13 UTC, Walter Bright wrote:
> On 12/20/2018 12:15 AM, Manu wrote:
>> It also hogs the `alias this` slot.
>
> C++ doesn't have alias this, so why would there be a slot for it?

Its nothing to do with C++. If you do struct "inheritance" with alias this, because there is no multiple alias this, you can't then alias this the struct to something else.