On Tuesday, 28 October 2014 at 02:34:14 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 28 Oct 2014 01:36:01 +0000
bitwise via Digitalmars-d <[email protected]> wrote:
I have actually found a work around as well, which was to wrap
the actual retrieval of the function address in a lambda, and
pass the lambda by template parameter instead:
it's not a "workaround", it's almost exactly what i did in my
sample,
just not that hairy.
Yea... I've tried several ways to clean this up.. the most
favorable being this:
MethodImpl!({ return &__traits(getMethod, SCOPE, m); })(...);
But, although the above has worked for me in a trivial test case,
it won't compile with my reflection implementation right now.
Definitely on the list though.
no one published it yet, not "no one attempted". i desperately
publish or perish! =)
yet the thing is still in post-alpha stage (but it works).
Yeah.. mine too.. I have only really been testing the common
cases. Not looking forward to unit-test time...
i also found some compiler bugs while writing it, but not yet
filled bugreports
I've hit a few myself... but the compiler messages have been a
bit obscure.. so I'm not even sure how to classify some of
the bugs I've hit.
I think should classify the one in the OP as something like:
"inconsistent availability of function pointers at compile time"
