Binding contexts

[Vladimir Panteleev via Digitalmars-d]

On Friday, 3 June 2016 at 15:14:59 UTC, Timon Gehr wrote:
>> https://github.com/dlang/dmd/pull/3361
>> ...
>
> Interesting. Not sure about this. It seems it should work by 
> analogy with this:
>
> struct Test{
>     int x=2;
>     int foo(){ return x; }
>     int call(alias a)(){ return a(); }
>     pragma(msg,Test().call!foo);
> }
>
> So I have implemented it. :)
> https://github.com/tgehr/d-compiler/commit/ea7cdcc43dce8fd05b64b872e83ac28905b81dff

Hah, very cool :)

> However, there are some funny cases:
>
> struct A{
>     int x;
>     this(int x){ this.x=x; }
>     int fun(){ return x;}
>     int[] caller(T)(T t){
>         int[] r;
>         r~=T.fun();
>         r~=(x++,t).fun();
>         return r;
>     }
> }
> struct B{
>     alias fun = A.fun;
> }
>
> pragma(msg, A(2).caller(B())); // [2,3]
> pragma(msg, A(2).caller(A(10))); // [2,10]
>
> I.e. this code exhibits 'special' behaviour when the passed 
> type is A.

Maybe when I don't follow your argument, but it acts exactly as 
before when the passed type is A. It also acts as before when you 
pass some other type with a regular old fun() method (i.e. when 
fun is static or the T.fun call is removed). It acts differently 
only when fun is an alias to a method in A, which otherwise 
wouldn't have compiled. Either way, this piggy-backs on that 
T.fun() works when fun is not static, which I think would not 
have been necessary had we had a nice syntax for __traits(child) 
(with the one I proposed it would be `this.(T.fun)();`).

Anyway, I don't feel too strongly about this one.

> It must work by default, otherwise libraries can accidentally 
> not support it. I think it should just be inferred. I.e. if the 
> template instance needs access to the context, that requirement 
> is propagated to the caller, otherwise it isn't. The arguments 
> that Kenji raises against it seem to be DMD-specific, no?

I must admit that I don't fully understand Kenji's explanation 
either.

> I share it. The main limitation that needs fixing is capture of 
> multiple contexts. Unfortunately I have not gotten around to 
> implementing multiple contexts and context inference myself so 
> far.

Yeah, multiple contexts would be the crown jewel. I've been told, 
though, that the idea that things can have at most one context 
pointer is very deeply rooted into DMD. I think Walter Bright is 
also not a fan of the idea, if I understand correctly his main 
counter-argument is that for untemplated function pointers, when 
it has 0 contexts it's just a function pointer, when it has 1 
context it's a delegate, when it has 2 or more contexts, it's 
something else, what is it - how would you describe its type in 
language syntax?