https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #7 from Steven Schveighoffer <[email protected]> --- (In reply to ZombineDev from comment #5) > I guess the trickiest problem to solve is what to do about is(typeof({ code; > })) and __traits(compiles, { code; }). Allowing those constructs to yield > true while containing non-betterc code would lead to logical contradictions. > Disallowing betterc code in such speculative contexts, while allowing it in > CTFE context would be strange. This is a good point. CTFE is hard because it still needs to compile, even though in this case you won't actually run that code. I would say that functions that are not going into the object symbol table can be compiled and run for CTFE only. If you do try to refer to that symbol during runtime, then throw the error. I don't know how hard this is to do, but it seems possible. possibly another answer is to revert the binding to druntime idup in betterC mode (obviously this worked before). --
