https://issues.dlang.org/show_bug.cgi?id=14145
--- Comment #10 from [email protected] --- I've also run into this before, and it's nigh impossible to debug if you didn't realize opDispatch was involved, because declining instantiation rather than generating a compile error may cause overload resolution to move to another, unintended overload, which may in turn have some deeply-nested templates which fails in some deeply-nested scope. You'd trace the error all the way back out the entire instantiation chain, then be left scratching your head as to why that template was even chosen in the first place, and it may take a while to realize opDispatch was the intended call target but due to suppression of errors it was silently skipped. As Steven said, whether opDispatch is chosen should not depend on the body, but only on the declaration and sig constraints. Any errors in the body should be a hard compile error. For method-forwarding templates, it should be easy enough to use __traits(hasMember) in opDispatch's sig constraints to decide whether or not to accept instantiation. Small price for greatly improving error reporting involving opDispatch. --
