Multiple alias this, what's the hold up?

Jonathan Marler johnnymarler at gmail.com
Sun Jun 16 18:25:28 UTC 2019


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


More information about the Digitalmars-d mailing list