On Saturday, 19 September 2015 at 18:36:49 UTC, Adam D. Ruppe
wrote:
On Saturday, 19 September 2015 at 17:46:27 UTC, Adam wrote:
I doubt anyone would read all so I'll stop now ;)
What you're asking is actually pretty easy. You can just write
a function that loops to form the object list yourself or you
could make the template add a static module constructor that
adds itself to the call list. Then you tag your object with its
typeinfo and use that as index into the list.
It might be, but I don't see how it can be done easily. I don't
know enough about D to know if it is implementable as a library
solution.
Suppose our templated function is
auto foo(T)(T x) { return x; }
and suppose we specialize it with
auto foo(T : object)(T x)
{
// The static part of the dispatch would look something like
static if (is(T == int ) {
return foo!int(cast(int)x);
....
// This stuff should all be optimized out at compile time
if/when the if passes
// In fact, it would never be called in this example since
int is more special than object. This part is more for when we
don't specialize on object and just create a wrapper for the
templated function.
// If no compile time dispatch, then we need to deal with the
unknown type using run-time reflection, we still want to dispatch
known types to the foo but no optimization can occur here
if (cast(int)x)
return foo!int(cast(int)x);
// Anymore?
else
return foo!object(x); // or foo!unknown(x)
}
foo!object should, in theory, work for all types, run-time or not.
But you say constructing foo!object is easy?!?!?! Remember, it
has to work in general for all types and number of parameters and
should always optimize to a direct template call when the compile
time checks are satisfied.
Also, the above doesn't allow for dynamic specialization, but
that would be easy to add with a lookup table.
The main problem I see, which you say is easy, is how to know the
list of types to check against? int is the only one used above,
but in reality, it depends on context. If the programmer used
foo!float, we would have to add that to the dispatch list. We
don't want to add it if he doesn't use it because then we are
including extra code in the binary that might never be used. It
may be used at run time but that's up to the programmer to make
sure it is include(by using it at compile time at least ones or
through some other method).
