Bug 14145 – opDispatch not considered when function body doesn't compile

dmd -c -o- main.d main.d(7): Error: function main.foo () is not callable using argument types (A) ---- void foo(){} struct A{ auto opDispatch(string op)() { writeln; } } void test(){ A.init.foo(); }

Not a bug (though a common mistake that the compiler offers zero help with) - you forgot to import std.stdio, so the opDispatch didn't compile and that's why it wasn't considered.

I forgot to mention: the naked 'writeln' was intentional in this bug report. the error occurs when the template body of opDispatch is not compilable (eg as in the example, import std.stdio is missing). The correct behavior IMO should be to say: error : could not resolve writeln. Furthermore to counter your argument saying this is not a bug: replace 'void fun(){}' by 'void foo(A a){}' now it compiles whereas is shouldn't.

Yeah, I agree that would be nice. And actually the docs don't say what should happen when opDispatch fails to compile http://dlang.org/operatoroverloading.html#dispatch so ok, now I agree with you, but I think it should be retitled to focus on just the opDispatch, the ufcs is unrelated. If it fails to compile it will say "no such property" which has the same root cause and is equally unhelpful.

You're right that UFCS is not root cause; i've updated the title. indeed, if we remove 'void foo' entirely it errors with "Error: no property 'foo' for type 'A'" instead of erroring with what it should: main.d(13): Error: 'writeln' is not defined, perhaps you need to import std.stdio; ? main.d(22): Error: template instance main.A.opDispatch!("foo") error instantiating

*** Issue 12951 has been marked as a duplicate of this issue. ***

*** Issue 8387 has been marked as a duplicate of this issue. ***

*** Issue 18863 has been marked as a duplicate of this issue. ***

This issue makes it practically impossible to use opDispatch with decent diagnostics, I think it should be solved as soon as possible. Would any compiler expert want to take it?

Ran into this recently also. What I have been doing to figure out why it's not working is to explicitly call opDispatch: A.init.opDispatch!"foo"(); IMO, if no other valid members exist, then opDispatch should be used, even if it doesn't compile (and the subsequent error message printed). I can see the utility in something like: struct A { T wrapped; auto opDispatch(string m, Args...)(Args args) { mixin("return wrapped." ~ m ~ "(args);"); } } Without having to use a constraint to ensure the call is possible. But the cost for this is pretty steep (confusing and misleading error messages). Whether opDispatch is *matched* or not should not depend on the body, only the signature and constraints. This is in line with all other function templates.

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.

@thewilsonator created dlang/dmd pull request #12288 "Fix issue 14145 - opDispatch not considered when function body doesn'…" fixing this issue: - Fix issue 14145 - opDispatch not considered when function body doesn't compile https://github.com/dlang/dmd/pull/12288

dlang/dmd pull request #12288 "Fix issue 14145 - opDispatch not considered when function body doesn'…" was merged into master: - 7fde6366daf146efc37d81f54d7265de2da8c3ff by Nicholas Lindsay Wilson: Fix issue 14145 - opDispatch not considered when function body doesn't compile https://github.com/dlang/dmd/pull/12288

Reopening, this is still not "fixed", the PR just changed the error messge.

Also adding Razvan to this one as it is a perpetually annoying opDispatch error bug Steve and I have had to deal with and complained about on the forum for years now. It used to work much better.

Regression introduced by: https://github.com/dlang/dmd/pull/1981

@RazvanN7 created dlang/dmd pull request #13679 "Fix Issue 14145 - opDispatch not considered when function body doesn't compile" fixing this issue: - Fix Issue 14145 - opDispatch not considered when function body doesn't compile https://github.com/dlang/dmd/pull/13679

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18944 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB