On Sunday, 27 September 2020 at 23:53:17 UTC, IGotD- wrote:
> On Sunday, 27 September 2020 at 23:34:31 UTC, 12345swordy wrote:
>>
>> What do you need multi alias this for anyway? Composite programming can already do what alias this can do expect implicit conversion.
>>
>> -Alex
>
> Yes, exactly that, creating multiple composites. I know that you can do it with mixin templates but kind of ugly. So if I have an implementation, I need a struct with that implementation in it's pure form and also structs where the implementation is inserted. Now you have a disconnected implementation and then a base struct to begin with. So if you want to reuse your code you basically have to make mixin templates of everything. Was it that solution you were referring to?

That is the solution that Walter has suggest to us. What issue that you take with this solution? Increase compile times?

-Alex

On Sunday, 27 September 2020 at 21:52:15 UTC, 12345swordy wrote:
>
> It been deprecated as Walter discovered that the current alias this introduce the diamond problem. That and other sorts of bugs that it has.
>
> -Alex

I must criticize the cop out that many language designers claim about the diamond problem. The diamond problem is mainly an academic problem which doesn't happen much in real life. I have programmed C++ for decades and I have only encountered the diamond problem once in my lifetime and this because I was hacking around, changed the solution shortly after so that it could do without "public virtual". You can come very far with multiple inheritance without the diamond pattern.

Are you saying that the detection of the diamond inheritance pattern is hard to implement, I would say that it isn't. If it detects, just emit a compiler error telling the user that such pattern isn't allowed.

The diamond problem is like a fantasy monster under the bed of the language designers.

On Monday, 28 September 2020 at 15:01:45 UTC, IGotD- wrote:
> On Sunday, 27 September 2020 at 21:52:15 UTC, 12345swordy wrote:
>> [...]
>
> I must criticize the cop out that many language designers claim about the diamond problem. The diamond problem is mainly an academic problem which doesn't happen much in real life. I have programmed C++ for decades and I have only encountered the diamond problem once in my lifetime and this because I was hacking around, changed the solution shortly after so that it could do without "public virtual". You can come very far with multiple inheritance without the diamond pattern.
>
> Are you saying that the detection of the diamond inheritance pattern is hard to implement, I would say that it isn't. If it detects, just emit a compiler error telling the user that such pattern isn't allowed.
>
> The diamond problem is like a fantasy monster under the bed of the language designers.


Then by all means created a new thread on this and argue your case, as I am not convinced that you think it is easy to implement the diamond inheritance detection.

-Alex

On Monday, 28 September 2020 at 15:01:45 UTC, IGotD- wrote:
> On Sunday, 27 September 2020 at 21:52:15 UTC, 12345swordy wrote:
>
> I must criticize the cop out that many language designers claim about the diamond problem. The diamond problem is mainly an academic problem which doesn't happen much in real life. I have programmed C++ for decades and I have only encountered the diamond problem once in my lifetime and this because I was hacking around, changed the solution shortly after so that it could do without "public virtual". You can come very far with multiple inheritance without the diamond pattern.
>
> Are you saying that the detection of the diamond inheritance pattern is hard to implement, I would say that it isn't. If it detects, just emit a compiler error telling the user that such pattern isn't allowed.
>
> The diamond problem is like a fantasy monster under the bed of the language designers.

I think this deserved to be better known:

The diamond problem is a *solved* problem by Eiffel language, which won the 2006 ACM Software System Award:

https://en.wikipedia.org/wiki/ACM_Software_System_Award

And I showed the concrete example here:

https://forum.dlang.org/thread/obqthozmxwzhvrafothw@forum.dlang.org

On Mon, Sep 28, 2020 at 05:59:19PM +0000, mw via Digitalmars-d wrote:
> I think this deserved to be better known:
> 
> The diamond problem is a *solved* problem by Eiffel language, which won the 2006 ACM Software System Award:
> 
> https://en.wikipedia.org/wiki/ACM_Software_System_Award

That award has nothing to do with the diamond problem.  There is nothing in the link that even mentions the diamond problem.


> And I showed the concrete example here:
> 
> https://forum.dlang.org/thread/obqthozmxwzhvrafothw@forum.dlang.org

As somebody already said, that's all well and good for Eiffel. It's not so clear how to integrate this nicely in D.


T

-- 
Старый друг лучше новых двух.

On Monday, 28 September 2020 at 17:16:31 UTC, 12345swordy wrote:
>
>
> Then by all means created a new thread on this and argue your case, as I am not convinced that you think it is easy to implement the diamond inheritance detection.
>
> -Alex

First limit multiple alias this to only be valid for basic types and structs (classes are disqualified for example). Then create a list of all the types that one alias this type has also searching that type for alias this types and up in the alias this hierarchy. If one or more of the same type is found in several alias this type lists, then abort compilation. Maybe there are more efficient ways to do this but you get the idea. Am I missing something?

On Monday, 28 September 2020 at 18:13:15 UTC, H. S. Teoh wrote:
> On Mon, Sep 28, 2020 at 05:59:19PM +0000, mw via Digitalmars-d wrote:
>
> As somebody already said, that's all well and good for Eiffel. It's not so clear how to integrate this nicely in D.

D has `alias` already, which can be used as Eiffel's `rename`, and by introducing the other same keywords (mechanism), we can adopt the Eiffel multiple inheritance.

D and Eiffel are close: D picked design-by-contract from Eiffel, but throw away multiple inheritance,

... and instead introduced sub-typing, mixin,

which Walter said:

https://forum.dlang.org/post/rb4seo$bfm$1@digitalmars.com

"""
The trouble was, it was inserted without realizing it was multiple inheritance, meaning its behaviors are ad-hoc and don't make a whole lot of sense when examined carefully.
"""

If we really want to fix it, can do it in D3.

On Monday, 28 September 2020 at 18:13:15 UTC, H. S. Teoh wrote:
> On Mon, Sep 28, 2020 at 05:59:19PM +0000, mw via Digitalmars-d wrote:
>> I think this deserved to be better known:
>> 
>> The diamond problem is a *solved* problem by Eiffel language, which won the 2006 ACM Software System Award:
>> 
>> https://en.wikipedia.org/wiki/ACM_Software_System_Award
>
> That award has nothing to do with the diamond problem.  There is nothing in the link that even mentions the diamond problem.

The two hallmarks of Eiffel, is design-by-contract and multiple inheritance, which is known in academics (in my former life).

it's a pity that

D only picked design-by-contract from Eiffel, but throw away multiple inheritance,

... and instead introduced sub-typing, mixin,

which Walter said:

https://forum.dlang.org/post/rb4seo$bfm$1@digitalmars.com

"""
The trouble was, it was inserted without realizing it was multiple inheritance, meaning its behaviors are ad-hoc and don't make a whole lot of sense when examined carefully.
"""

If we really want to fix it, can do it in D3.

On Mon, Sep 28, 2020 at 06:28:05PM +0000, mw via Digitalmars-d wrote:
> On Monday, 28 September 2020 at 18:13:15 UTC, H. S. Teoh wrote:
> > On Mon, Sep 28, 2020 at 05:59:19PM +0000, mw via Digitalmars-d wrote:
> > 
> > As somebody already said, that's all well and good for Eiffel. It's not so clear how to integrate this nicely in D.
> 
> D has `alias` already,
[...]

`alias this` is one of the things that seemed like a good idea at the time, but is turning out to be something that leads to code smells.  If anything, we'd like to get rid of it rather than extend it!


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On Monday, 28 September 2020 at 18:44:51 UTC, H. S. Teoh wrote:
> On Mon, Sep 28, 2020 at 06:28:05PM +0000, mw via Digitalmars-d wrote:
>> On Monday, 28 September 2020 at 18:13:15 UTC, H. S. Teoh wrote:
>> > On Mon, Sep 28, 2020 at 05:59:19PM +0000, mw via Digitalmars-d wrote:
>> > 
>> > As somebody already said, that's all well and good for Eiffel. It's not so clear how to integrate this nicely in D.
>> 
>> D has `alias` already,
> [...]
>
> `alias this` is one of the things that seemed like a good idea at the time, but is turning out to be something that leads to code smells.  If anything, we'd like to get rid of it rather than extend it!

On a second thought, I agree we'd better not to extend `alias`.

It's all about resolve name clashing: `alias` means synonyms; let's just borrow from Eiffel, instead of re-invent the wheels: the main concepts to solve multiple inheritance are these 5 keywords:

https://www.eiffel.org/doc/eiffel/Eiffel_programming_language_reserved_words

`rename`
`export`
`undefine`
`redefine`   -- D's override
`select`