Futurism lib (futures in D)

[Daniel Keep]

Kevin Bealer wrote:
> == Quote from Daniel Keep (daniel.keep+lists at gmail.com)'s article
> 
>>Of course, the alternative is to move the function out to the template
>>argument as an alias, and THEN specialise on the argument type of that
>>(which I've done in my OGL/SDL safety templates), which would make it
>>look like this:
>>
>>     make_future!(work)(1234, "some string");
>>
>>At least, I think it would :P
>>
>>This is one of the reasons I love D: programming in it is like opening
>>up a shiny russian doll: every time you think you know what's going on,
>>there's a whole 'nother layer to play with.
> 
> 
> I didn't fully appreciate this statement until I got the solution working.
> Now my head hurt like back when I was learning recursion for the first time,
> which is a sign that my mental software is getting a refactoring. ;)
> 
> Template metaprogramming requires another layer of meta-thinking.  Practice
> helps too (with the syntax especially).  I think I'm finally starting to
> "absorb" what tuples are doing and why variadic stuff works the way it does.

I know the feeling.  There's nothing quite like the moment when 
something new finally clicks into place.

> The requirement for "[]" is gone now, but more fundamentally, conversions
> between arguments and parameters should happen in the 'right direction'.
> 
> This is accomplished by extracting the parameters from the delegate inside
> of make_future() (using a helper template).  The changes are in SVN but for
> those of you just reading along, these are the modified lines:
> 
> template FutureTypeGroup(Delegate, Args...) {
>     alias ReturnType!(Delegate)          Return;
>     alias ParameterTypeTuple!(Delegate)  Params;
>     alias Future!(Return, Params)        TFuture;
> }
> 
> FutureTypeGroup!(Delegate, Args).TFuture
> make_future(Delegate, Args...)(Delegate cmd, Args args)
> {
>     return new FutureTypeGroup!(Delegate, Args).TFuture(cmd, args);
> }

Now, see, I hadn't thought of trying that: using another level of 
indirection to coax the compiler into handling the conversions itself. 
Very nice.

> I think the fact that this change affects so few lines is a testament
> to the increasing expressiveness of D.
> 
> Kevin

That, and our ability to abuse^Hmake use of some of D's advanced features :)

	-- Daniel