Multiple alias this, what's the hold up?

[Timon Gehr]

On 18.06.19 02:01, Mike Franklin wrote:
> On Monday, 17 June 2019 at 18:31:18 UTC, Timon Gehr wrote:
>> On 17.06.19 15:48, Mike Franklin wrote:
>>> void main()
>>> {
>>>      S s;
>>>      s = 1;
>>>      int i = s;  // No way to make this work in the library. We need 
>>> `opAssignRight`.
>>> }
>>
>> This is not an assignment. It is an initialization. opAssignRight 
>> would do nothing for this case.
>>
> 
> I don't disagree, but that's not what `alias this` does.
> 
> ```
> struct S
> {
>      int i = 42;
>      alias i this;
> }
> 
> void main()
> {
>      S s;
>      int i = s;
>      writeln("Init: ", i.init, " Value: ", i);
> }
> ```
> https://run.dlang.io/is/ra5may
> 
> Output:
> Init: 0 Value: 42
> ...

I am not sure what your point is. Initializations don't affect the .init 
value:

struct S{
     int x=42;
     pragma(msg,x.init); // 0
}


void main(){
     int x=42;
     pragma(msg,x.init); // 0
}


>>> I think if we had an `opAssignRight` feature (with friends) we could 
>>> move the entire implementation of `alias this` to the library.
>>
>> I don't think that works. (And I don't necessarily agree that it is 
>> desirable. See Ethan's excellent post noting issues with compile times.)
> 
> Sorry, I couldn't find the post.  If you explicitly reference it, I'll 
> read it.

It's easy to find in the threaded view of a news reader. The relevant 
part is this:

On 17.06.19 19:41, Ethan wrote:
> Without multiple alias this, you have to do exactly what I do with
> Binderoo C++ binding and parse each relevant object to generate wrapper
> functions for it. Up goes the compile time. 


> If you're saying that implementing `alias this` in the library 
> would negatively affect compile times, I think you may be right.  But 
> that is a performance bug in the compiler's implementation.  newCTFE and 
> other efforts could help alleviate that.

Maybe, but I doubt that iterating over all members of a structure and 
generating code for each of them will ever be very fast.

> ...
> 
> multiple alias this (i.e. DIP66) was approved almost 5 years ago and 
> despite mutliple attempts at the implementation, it still has not 
> materialized.  The primary blocker is the complexity it introduced in 
> the compiler 
> (https://github.com/dlang/dmd/pull/8378#issuecomment-403261763). 
> Multiple alias this is not going to happen unless it's delegated to the 
> library.  It seems to me that the best way forward is whatever language 
> feature is missing (`opAssignRight`, `opImplicitCast`, `opWhatever`) so 
> it can be implemented in the library, and potentially enable additional 
> idioms in D at the same time.
> 
> Mike

There should be opImplicitCast for conversions, but I don't know how you 
would import scopes correctly (with multiple overload sets that have the 
same name, etc) without compiler support. For a significant subset of 
use cases, it would suffice if in addition to opImplicitCast, this just 
worked:

struct T{
     int x;
}

struct S{
     T t;
     alias x=t.x;
}

void main(){
     S s;
     import std.stdio;
     writeln(s.x); // Error: need `this` for `x` of type `int`
}

If this was made to work, probably multiple `alias this` could be 
implemented semi-correctly by generating some mixin templates that mix 
in such alias declarations.