Binding contexts

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 3 08:14:59 PDT 2016


On 03.06.2016 13:11, Vladimir Panteleev wrote:
>
> I think that alias template parameters and context binding are a very
> rich and unexplored area of D, which will allow writing some really
> efficient and composable code. A while ago I created a few DMD pull
> requests with related improvements, and based on those DMD pull requests
> I wrote an allocator and serialization library. The entire code was
> messy but extremely efficient (e.g. the "this" pointer was shared
> between all composed layers of the entire allocator instance).
>
> DMD pull requests:
>
> https://github.com/dlang/dmd/pull/3329
> https://github.com/dlang/dmd/pull/3345

I agree that those cases should work.

> 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


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.


> Compiler capability tests:
>
> https://github.com/CyberShadow/ae/blob/master/utils/meta/caps.d
>
> Allocators (note that this predates std.experimental.allocator):
>
> https://github.com/CyberShadow/ae/blob/master/utils/alloc.d
>
> Serialization:
>
> https://github.com/CyberShadow/ae/tree/master/utils/serialization
>
> For personal use, I still use a hacked compiler with
> https://github.com/dlang/dmd/pull/3884 reverted, even though at the time
> I argued in favor of that change (since the introduction of field
> context binding broke code). It is just too useful.
> ...

It works with my compiler too. There shouldn't be any restrictions on 
context binding.

> A while ago Kenji proposed "static alias", to explicitly control whether
> an alias argument passes context or not (sometimes not passing context
> is required, e.g. if the parameter will be used only for introspection
> or with my __traits(child)):
>
> https://wiki.dlang.org/Brush_Up_Language_Features#Nested_Symbols
>
> I think by now we would need "this alias" since fields and methods no
> longer bind with context to alias parameters.
> ...

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?

Additionally, I'm in favor of having both static alias and this alias.

> I would like to some day wrap all of the above work together into a
> coherent proposal to improve D aliases, but haven't had the time/energy
> so far (few people seem to share my enthusiasm for the subject :)).
> Perhaps for DConf 2017...

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.





More information about the Digitalmars-d mailing list