function pointer bug?

[bitwise via Digitalmars-d]

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 <digitalmars-d at puremagic.com> 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"