On 16.06.19 08:08, 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.

No. It's multiple imports. You have no vtable to populate, so you can just throw a compile-time error if some lookup is ambiguous and require explicit disambiguation, like for imports.

> 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.)

On Sunday, 16 June 2019 at 14:23:37 UTC, Timon Gehr wrote:
> On 16.06.19 08:19, Jonathan Marler wrote:
>> On Sunday, 16 June 2019 at 01:21:16 UTC, Timon Gehr wrote:
>>> On 16.06.19 03:04, Jonathan Marler wrote:
>>>> On Saturday, 15 June 2019 at 23:30:09 UTC, 12345swordy wrote:
>>>>> [...]
>>>>
>>>> Maybe we could add it as an optional feature enabled with a command-line option?
>>>>
>>>> I think there's a command line format for features like this "-feature=miltialias" or something.
>>>> ...
>>>
>>> That probably won't fly.
>>>
>>>> That way if there really are issues we could demonstrate them and remove the feature later, or if no issues are found it could be enabled by default.
>>>
>>> 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.
>> 
>> Having a hard time trying to figure out what you mean here.  I'm not sure what you mean by "multiple import declarations".  Is this what you mean?
>> 
>> import std.stdio;
>> import std.stdio;
>> 
>> Or maybe this?
>> 
>> import std.stdio;
>> void foo()
>> {
>>      import std.stdio;
>> }
>> 
>> Then you said "Implicit conversions could use the same lookup rules", but I'm not sure what you're saying there either.  Maybe if I understood what you meant my "import declarations" then it would make sense?
>> ...
>
> Probably. What I mean is multiple imports of different modules:
>
> import std.file;
> import std.stdio;
>
> void main(){
>     write("hello","world"); // error: ambiguous
> }
>
> This is the same situation as:
>
> struct S{
>     void write(T...)(string file,T args){ ... }
> }
> struct T{
>     void write(T...)(T args){ ... }
> }
>
> struct U{
>     S s;
>     T t;
>     alias s this;
>     alias t this;
> }
>
> void main(){
>     U u;
>     u.write("hello","world"); // error: ambiguous
> }
>
> Basically any complaint against multiple `alias this` can be turned into a complaint against multiple imports, and all the solutions already exist in D's module system.

Now I gotcha.

One idea is to allow multiple alias this to use a search order, i.e.

struct Foo
{
    Bar bar;
    Baz baz;
    alias bar, baz this; // search bar, then baz
}

Foo foo;

foo.func();

In this case it would try Bar first and fallback to baz.

Of course, you could also just make it an error if you have multiple resolutions, which is what I think dmd does with multiple import matches.  In any case, I don't think it matters much as these cases would be fairly uncommon.  If you have a conflict, you can explicitly select one or the other (foo.bar.func() or foo.baz.func()).

On Sunday, 16 June 2019 at 06:08:54 UTC, 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.

This is not true! Alias this is does not use inheritance at all. There is no vtable for alias this. It's purely compile time. It's purely to simplify dispatching.

https://dlang.org/spec/class.html#AliasThis

Says nothing about inheritance.

There is no diamond problem so I really have no idea what you are talking about.

Alias this is entirely for convinces and is only compile time.

The reason why the diamond problem is an issue is because it can occur without the compiler being able to determine that is is a problem(such as with plugins).

With alias this, the compiler always can determine what is going.

I think you are mistaken here. I could be wrong. Do you have proof of what you claim?


struct X
{
   int q;
   alias q this;
}


Where is the inherence in this code?

as far as the docs they simply say that we can treat any instance x of X as if we used x.q.

Hence, instead of having to write x.q all over the place we can write x.

How can this ever create a diamond problem? And if it did how would that not be caught at compile time?

On Sunday, 16 June 2019 at 18:25:28 UTC, Jonathan Marler wrote:
> Of course, you could also just make it an error if you have multiple resolutions, which is what I think dmd does with multiple import matches.  In any case, I don't think it matters much as these cases would be fairly uncommon.  If you have a conflict, you can explicitly select one or the other (foo.bar.func() or foo.baz.func()).

That reminded me of private symbols that are publicly aliased. Currently this is not possible:

struct S {
  private int a;
  public alias a this;
}

But I vaguely remember talk about implementing this. Tried to find a bug report but couldn't. Has there been discussion on allowing this or why not to allow it?

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.


>> 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.

On Sunday, 16 June 2019 at 22:14:19 UTC, Walter Bright wrote:
> On 6/16/2019 7:39 AM, Timon Gehr wrote:
>> No. It's multiple imports.
>
> D already has multiple imports with template mixins. If multiple imports is what people want, it's already there.

Actually, I'll disagree with both of you. I think alias this is really about enabling implicit conversion to the type of alias this. And multiple implicit conversion is obviously useful.



Though speaking of template mixin, I think it would be kinda cool to be able to mixin a struct or maybe a .tupleof thingy; just treat a struct as if it was a mixin template.

On 6/16/2019 2:33 AM, Mike Franklin wrote:
> I refer you to this StackOverflow question (https://stackoverflow.com/questions/255553/is-it-possible-to-implement-mixins-in-c) where a C# user was looking for a convenient way to reuse and aggregate implementations.  The second comment to the question says it all:
> 
>> I find it annoying that C++ experts make statements like "Prefer composition to inheritance" yet the language (C++ or C#) offers precious little help to do the "right thing".

Be careful about dismissing what experts say. Sometimes it takes many years of experience to understand that seemingly good ideas are not that good after all.

I don't do use a lot of programming techniques I thought were way cool in my 20's, but now I understand are crap, like <cough cough>macros</cough cough>.

On 17.06.19 00:28, Adam D. Ruppe wrote:
> On Sunday, 16 June 2019 at 22:14:19 UTC, Walter Bright wrote:
>> On 6/16/2019 7:39 AM, Timon Gehr wrote:
>>> No. It's multiple imports.
>>
>> D already has multiple imports with template mixins. If multiple imports is what people want, it's already there.
> 
> Actually, I'll disagree with both of you. I think alias this is really about enabling implicit conversion to the type of alias this. And multiple implicit conversion is obviously useful.
> ...

Sure, it does that too, but this doesn't really inform the design. (Furthermore, I think it is actually pretty annoying that those two aspects of `alias this` are mixed together into the same language feature).
And anyway, right now, alias this is a bad mechanism for this because it does not allow introspection on the expected type to generate code that performs the conversion. If there was just general expected-return-type-based IFTI (instead of just for non-aliased template function literals), single alias this would suffice for your use case.

On 17.06.19 00:14, 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.
> ...

No. Mixins and imports are not the same thing. E.g., this code is fine:

import std.stdio;

void main(){
    writeln("hello world!");
}

This code is horrible (it does not even compile):

mixin(import("std/stdio.d"));

void main(){
    writeln("hello world!");
}

(Whether the automated copy-pasting of code happens before or after parsing doesn't really matter.)

On Sunday, 16 June 2019 at 22:28:56 UTC, Walter Bright wrote:

>> I refer you to this StackOverflow question (https://stackoverflow.com/questions/255553/is-it-possible-to-implement-mixins-in-c) where a C# user was looking for a convenient way to reuse and aggregate implementations.  The second comment to the question says it all:
>> 
>>> I find it annoying that C++ experts make statements like "Prefer composition to inheritance" yet the language (C++ or C#) offers precious little help to do the "right thing".
>
> Be careful about dismissing what experts say. Sometimes it takes many years of experience to understand that seemingly good ideas are not that good after all.
>
> I don't do use a lot of programming techniques I thought were way cool in my 20's, but now I understand are crap, like <cough cough>macros</cough cough>.

I think you may have misunderstood what that user and I are saying.  We're not dismissing what the experts say, in fact we, for the most part, agree with them.  What we're saying is that the facilities for composition in C# and C++ are lacking, yet those experts, disingenuously, aren't acknowledging it.

D has an opportunity, and is better positioned, to do better.  If C++ style multiple inheritances is not the answer, what is?  Eiffel's multiple inheritance?  D's `alias this`? Design-by-introspection metaprogramming? "Suck it up, and get typing!"?

Mike