If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

Not that I know of. There's no way to switch based on run time/compile
time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.

If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

Not that I know of. There's no way to switch based on run time/compile
time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.

If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

Not that I know of. There's no way to switch based on run time/compile
time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.

Is this a case for version(CompileTime){}?

No because it would also compile this block into the binary.
The easy way is of course to have different symbols for compile-time and
run-time. But this doesn't go well with generic programming where the function
needing such a check can be deep in the compile-time call stack.
For example:
int foo() { return bar + 1; }
int bar() { return foobar * 2; }
int foobar() {
static if(isCompileTime) return ...; /// asm cannot execute at compile time,
needed to keep foo and bar able to do CTFE
else asm { ...; } /// asm optimized for runtime
}

If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.

The easy way is of course to have different symbols for compile-time and
run-time. But this doesn't go well with generic programming where the function
needing such a check can be deep in the compile-time call stack.
For example:
int foo() { return bar + 1; }
int bar() { return foobar * 2; }
int foobar() {
static if(isCompileTime) return ...; /// asm cannot execute at compile time,
needed to keep foo and bar able to do CTFE
else asm { ...; } /// asm optimized for runtime
}

If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.

time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.