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.
