Looks good. But with this version is the generic type name known at compile-time?
Is it being available at compile time an issue? Since julia is JIT-compiled, is there much of a difference performance wise? I’d imagine if the compiler can’t prove either way if the type is going to change, it’s not going to replace that call with the concrete type at compile time anyway.
The function provided by @mohamed82008 is by definition runtime, since the call has to happen or it gets inlined if it’s not statically provable.
There is a difference in the sense that if the generic name gets known at compile time, the call to name(...) gets optimized away. I don’t see why this information cannot be made available to the compiler.
You can mark that piece of code with @inline to mark it as inlineable to the compiler, circumventing the (minimal) calling overhead.
What use case do you have for this? What do you want to do with that type?
1 Like
The metaprogramming solution from @mohamed82008 can be generalized using subtypes (in the InteractiveUtils module, loaded when in REPL mode but needs importing otherwise):
for T in subtypes(AbstractMyType)
@eval f(x::$T) = $T
end
The downside is that if new subtypes are defined after this executes, they won’t be recognized.
1 Like