Futurism lib (futures in D)

Daniel Keep daniel.keep+lists at gmail.com
Mon Jan 22 11:01:44 PST 2007


Kevin Bealer wrote:
> == Quote from Daniel Keep (daniel.keep+lists at gmail.com)'s article
> 
>>Kevin Bealer wrote:
 >>>Daniel Keep wrote a whole buncha junk, *yoink!*
>>
>>Looks good; more sophisticated than my own.  A few initial thoughts:
>>
>>1) Have you considered stealing my code and using the "future(...)"
>>syntax I used?  It seems a bit cleaner than having to alias the class,
>>and then instantiating objects.

P.S.  Of course I don't mind; I'm happy to be able to contribute!

> By the way, I've done this part -- I wrote a function called make_future,
> (can't use "future" since thats the module name) and modified the templates
> in future.d to store the argument tuples.
> 
> There is still things I'm not sure about:
> 
> 1. Why is a foreach() loop needed to copy a tuple value to another tuple of
>    the same type?

I tried assigning directly, and it didn't like that, hence the foreach 
loop.  Since it's working on template arguments, it *should* unroll at 
compile time.

> 2. You can't pass a char[10] (for example) to a function that uses a char[]
>    input -- instead, you need to ask for the slice, for example, using
>    syntax like:
> 
>      make_future(& work, 1234, "some string"[]);
>                                             ^^
> 
>    I could probably fix this if I knew how to use static if or "is" to find
>    out whether something is a static array or not.  For now, the above syntax
>    is a not-too-painful workaround.
> 
> Kevin

Ah yes, I've had a few problems with this myself (in other things).

The trick here is that instead of specialising on the type of the 
function, I'm specialising on the type of the arguments supplied.  In 
most cases, this isn't a problem, but it does cause problems for arrays 
(and possibly a few other cases).

(I think that) what you need to do is to check to see if an argument is 
an array, and then check the corresponding type in the function call, 
and make any necessary casts/conversions.

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.

Oh hang on, that was supposed to be the "peeling an onion" metaphor, 
wasn't it?  Oh well...

	-- Daniel "No, ogres are NOT like cake!"



More information about the Digitalmars-d-announce mailing list