• Adam D. Ruppe (30/30) Dec 02 2009 I've been working on making std.variant work seamlessly with delegates

"Adam D. Ruppe" <destructionator gmail.com> writes:

I've been working on making std.variant work seamlessly with delegates
the last day and a half - the last piece to making std.javascript_in_d :)
and am almost there - just have one thing that I either haven't solved or
adequately worked around* so far: opCall.

The spec says that static opCall is called whenever a struct is initialized
with a type other than itself:

S a = 10; // calls S.opCall(10);

This is problematic, because I'd like to use opCall to forward to the inner
delegate:

Variant a = &someFunc;
a(10); // should call someFunc(10)

As I have it now, it sometimes does this... sometimes doesn't compile, and
sometimes just randomly segfaults/illegal instruction (&this == random -
the compiler is assuming the function is static, but it isn't)).


What I'd like to see is:

a) the current static opCall functionality is moved somewhere. Maybe to
   a constructor, or maybe just use opAssign instead. I lean toward the latter.

b) Non-static opCall work like I want: where S is a struct:
	S a;
	a(T); // --> S.opCall(T); and don't forget to pass along this!

S() would be either a constructor call or an automatic handy field
initialization thing. Actually, static opCall could possibly even be kept,
as long as it doesn't interfere with non-static opCalls:

S a = S(); // static call if you really want it
a() ; // non-static call - don't let the static one interfere!



Are there any downsides to do this? It seems like the old opCall is solving
a problem that is better solved with a more dedicated method.

-- 
Adam D. Ruppe
http://arsdnet.net