On 06/15/2019 11:08 PM, Walter Bright wrote:
> On 6/15/2019 6:21 PM, Timon Gehr wrote:
>> In terms of lookup, the issues with multiple alias this are the same as the issues with multiple import declarations. Implicit conversions could use the same lookup rules, but there would need to be a way to disambiguate. The code in the compiler that implements import declarations is unlikely to be easily reusable.
> 
> Multiple alias this is multiple inheritance. Generally, if you find yourself wanting multiple inheritance, it's likely time to rethink the data structures.

Does this mean multiple alias this will never happen?

I would love to remove a section in my book that was added in the hopes of seeing this feature "any day now". :)

I like the example I came up with though: A TeachingAssistant class that can appear in a Student context as well as in a Teacher context.

Ali

On Tuesday, June 18, 2019 4:08:49 PM MDT Ali Çehreli via Digitalmars-d wrote:
> On 06/15/2019 11:08 PM, Walter Bright wrote:
> > On 6/15/2019 6:21 PM, Timon Gehr wrote:
> >> In terms of lookup, the issues with multiple alias this are the same as the issues with multiple import declarations. Implicit conversions could use the same lookup rules, but there would need to be a way to disambiguate. The code in the compiler that implements import declarations is unlikely to be easily reusable.
> >
> > Multiple alias this is multiple inheritance. Generally, if you find yourself wanting multiple inheritance, it's likely time to rethink the data structures.
>
> Does this mean multiple alias this will never happen?
>
> I would love to remove a section in my book that was added in the hopes of seeing this feature "any day now". :)
>
> I like the example I came up with though: A TeachingAssistant class that can appear in a Student context as well as in a Teacher context.

It definitely looks like a DIP would be required for multiple alias this-es to become a thing, and whatever was in the DIP would have to convince Walter that it doesn't have the problems that multiple inheritance has. Certainly, it's not simply a matter of someone needing to implement it, which is often how the issue is portrayed, though a solid implementation could help convince Walter.

I expect that it's perfectly safe to remove mentioning multiple alias this-es from your book and that it would give a far more accurate representation of the state of D. Acting like it's just a matter of time before multiple alias this-es get added to D would be giving folks the wrong idea with how things stand. And if someone actually comes up with a proposal that convinces Walter, it's not like it would be hard to grab what you had and re-add it with any necessary changes (at least if you have your book in source control like I would think you would).

Based on some of the discussions on the topic, it seems more likely to me that alias this will be replaced with some other feature than we'll ever get the ability to have multiple alias this-es on the same type.

- Jonathan M Davis

On Tuesday, 18 June 2019 at 00:58:58 UTC, Exil wrote:
> On Sunday, 16 June 2019 at 22:14:19 UTC, Walter Bright wrote:
>> On 6/16/2019 7:39 AM, Timon Gehr wrote:
>>> On 16.06.19 08:08, Walter Bright wrote:
>>>> Multiple alias this is multiple inheritance.
>>> 
>>> No. It's multiple imports.
>>
>> D already has multiple imports with template mixins. If multiple imports is what people want, it's already there.
>
> Isn't there an entire thread arguing for the inclusion of *single* inheritance. Not sure how you can say we have multiple inheritance without even having inheritance (for structs).
>
>>>> Generally, if you find yourself wanting multiple inheritance, it's likely time to rethink the data structures.
>>> 
>>> Only if your programming language gets MI wrong. C++ gets MI wrong. This is how to do multiple inheritance: https://www.eiffel.org/doc/eiffel/ET-_Inheritance
>>> 
>>> (Ignore the section about covariance. Eiffel gets that part totally wrong.)
>>
>> Designing a decent object is hard enough, and most everybody (including me) do a lousy job of it. When people start using MI, the mess becomes incredible. Maybe in another 20 years ago I'll get good enough to be able to write a sensible MI object.
>
> I feel like without virtual functions it isn't really multiple inheritance. Alias this is just syntactic sugar so that you don't have to specify the variable to use it. Things like the diamond problem don't exist because you can't override functions in structs.

The diamond problem in theory is possible but the compiler implementation would error with recursion when making type semantic.

On Tuesday, 18 June 2019 at 23:33:12 UTC, user1234 wrote:
> On Tuesday, 18 June 2019 at 00:58:58 UTC, Exil wrote:
>> On Sunday, 16 June 2019 at 22:14:19 UTC, Walter Bright wrote:
>>> On 6/16/2019 7:39 AM, Timon Gehr wrote:
>>>> On 16.06.19 08:08, Walter Bright wrote:
>>>>> Multiple alias this is multiple inheritance.
>>>> 
>>>> No. It's multiple imports.
>>>
>>> D already has multiple imports with template mixins. If multiple imports is what people want, it's already there.
>>
>> Isn't there an entire thread arguing for the inclusion of *single* inheritance. Not sure how you can say we have multiple inheritance without even having inheritance (for structs).
>>
>>>>> Generally, if you find yourself wanting multiple inheritance, it's likely time to rethink the data structures.
>>>> 
>>>> Only if your programming language gets MI wrong. C++ gets MI wrong. This is how to do multiple inheritance: https://www.eiffel.org/doc/eiffel/ET-_Inheritance
>>>> 
>>>> (Ignore the section about covariance. Eiffel gets that part totally wrong.)
>>>
>>> Designing a decent object is hard enough, and most everybody (including me) do a lousy job of it. When people start using MI, the mess becomes incredible. Maybe in another 20 years ago I'll get good enough to be able to write a sensible MI object.
>>
>> I feel like without virtual functions it isn't really multiple inheritance. Alias this is just syntactic sugar so that you don't have to specify the variable to use it. Things like the diamond problem don't exist because you can't override functions in structs.
>
> The diamond problem in theory is possible but the compiler implementation would error with recursion when making type semantic.

It's not possible, that's why the compiler would give an error. It wouldn't even be recursion, it would see both available. That's if it is even implemented that way. With classes the only "alias this" that are checked are of the type being used. It doesn't check the "alias this" of the base class.

https://run.dlang.io/is/EqliF5

On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:

> It definitely looks like a DIP would be required for multiple alias this-es to become a thing, and whatever was in the DIP would have to convince Walter that it doesn't have the problems that multiple inheritance has.

DIP66 (https://wiki.dlang.org/DIP66) was already created and approved.  Did you have something else in mind?

Mike

On Tuesday, June 18, 2019 10:09:24 PM MDT Mike Franklin via Digitalmars-d wrote:
> On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:
> > It definitely looks like a DIP would be required for multiple alias this-es to become a thing, and whatever was in the DIP would have to convince Walter that it doesn't have the problems that multiple inheritance has.
>
> DIP66 (https://wiki.dlang.org/DIP66) was already created and approved.  Did you have something else in mind?

Given Walter's more recent statements on the matter, it doesn't sound like it's approved anymore. He's repeatedly compared having multiple alias this-es to multiple inheritance and expressed that it's a bad idea.

- Jonathan M Davis

On Wednesday, 19 June 2019 at 05:53:42 UTC, Jonathan M Davis wrote:
> On Tuesday, June 18, 2019 10:09:24 PM MDT Mike Franklin via Digitalmars-d wrote:
>> On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:
>> > It definitely looks like a DIP would be required for multiple alias this-es to become a thing, and whatever was in the DIP would have to convince Walter that it doesn't have the problems that multiple inheritance has.
>>
>> DIP66 (https://wiki.dlang.org/DIP66) was already created and approved.  Did you have something else in mind?
>
> Given Walter's more recent statements on the matter, it doesn't sound like it's approved anymore. He's repeatedly compared having multiple alias this-es to multiple inheritance and expressed that it's a bad idea.
>
> - Jonathan M Davis

It's fair to say that multiple alias this and multiple inheritance have similarities, but some have argued that the "bad parts" of multiple inheritance don't apply to 'alias this' (i.e. the "Diamond Problem").  I'm hoping Walter will reveal what problems he claims apply to both as I haven't seen anyone else point them out yet.

On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:
> [...]
>
> I expect that it's perfectly safe to remove mentioning multiple alias this-es from your book and that it would give a far more accurate representation of the state of D. Acting like it's just a matter of time before multiple alias this-es get added to D would be giving folks the wrong idea with how things stand. And if someone actually comes up with a proposal that convinces Walter, it's not like it would be hard to grab what you had and re-add it with any necessary changes (at least if you have your book in source control like I would think you would).
>
> [...]

If that's indeed the case it should probably be removed from the
spec[1] as well.

[1] https://dlang.org/spec/class.html#alias-this (subsection 7)

On Wednesday, 19 June 2019 at 06:05:31 UTC, Jonathan Marler wrote:
> On Wednesday, 19 June 2019 at 05:53:42 UTC, Jonathan M Davis wrote:
>> On Tuesday, June 18, 2019 10:09:24 PM MDT Mike Franklin via Digitalmars-d wrote:
>>> On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:
>>> > It definitely looks like a DIP would be required for multiple alias this-es to become a thing, and whatever was in the DIP would have to convince Walter that it doesn't have the problems that multiple inheritance has.
>>>
>>> DIP66 (https://wiki.dlang.org/DIP66) was already created and approved.  Did you have something else in mind?
>>
>> Given Walter's more recent statements on the matter, it doesn't sound like it's approved anymore. He's repeatedly compared having multiple alias this-es to multiple inheritance and expressed that it's a bad idea.
>>
>> - Jonathan M Davis
>
> It's fair to say that multiple alias this and multiple inheritance have similarities, but some have argued that the "bad parts" of multiple inheritance don't apply to 'alias this' (i.e. the "Diamond Problem").  I'm hoping Walter will reveal what problems he claims apply to both as I haven't seen anyone else point them out yet.

That's not to say that alias this itself doesn't have its design problems (i.e. searchability is hard - but that can be fixed by changing the syntax a bit), and there's this gotcha:

class A { int i; void f() { writeln(i); } }
class B {
    A a;
    alias a this;
}

void main() {
    auto b = new B();
    if (b !is null) {
        b.f; // Wait what? - proceed to spend days going crazy.
    }
}

And then you have at least the problem that any implicit behaviour comes with - traceability.

Question: can the compiler issue an Error instead of segfaulting when directing flow to a reference type alias this member? It would make bug tracing the gotcha above a million times more easy.

But I am also curious about what the overlapping problems with MI are:

With regards to implementation details, the diamond problem errors out, and the layout problem is defined by member layout, which is also solved. And implicitness is desirable in some cases.

Also remember, it's "prefer" composition over inheritance. Not "never use". As always, there's a balance and it depends on the situation.

On Wednesday, June 19, 2019 1:29:40 AM MDT Les De Ridder via Digitalmars-d wrote:
> On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis wrote:
> > [...]
> >
> > I expect that it's perfectly safe to remove mentioning multiple alias this-es from your book and that it would give a far more accurate representation of the state of D. Acting like it's just a matter of time before multiple alias this-es get added to D would be giving folks the wrong idea with how things stand. And if someone actually comes up with a proposal that convinces Walter, it's not like it would be hard to grab what you had and re-add it with any necessary changes (at least if you have your book in source control like I would think you would).
> >
> > [...]
>
> If that's indeed the case it should probably be removed from the spec[1] as well.
>
> [1] https://dlang.org/spec/class.html#alias-this (subsection 7)

IMHO, regardless of whether we intend to add the ability to have multiple alias this-es, the spec really shouldn't say that they're a thing when they're not actually implemented - even if it then follows that up by saying that they're not currently implemented like it does right now.

- Jonathan M Davis