13steinj
commented
1 month ago Actually, part of me expects SFINAE rules to still apply and for the generated bar(A) from bar(auto) to fail but not cause an ambiguous overload error (but not a standardese expert by any means).
shafik
https://github.com/llvm/llvm-project/commit/6dc1636815cb9321657f1cb7ac87a46553870dc7 aka implementation of
[dcl.fct]changes introduced by https://wg21.link/P0929 causes the following example to trigger an ambiguous overload resolution (play around with commenting out functions at your leisure), regressing from previous behavior (the defined overload with an abstract parameter type fails SFINAE):https://gcc.godbolt.org/z/zasedovKG
```cpp struct A { virtual void a() = 0; }; void bar(auto&&) {} void bar(auto) {} // void bing(A&); // void bing(A); // void bing(A) {}; // comment out at leisure void baz(A& a) { bar(a); // bing(a); } ```A change in behavior is expected, but an ambiguity error is not (personally).
From the wording, I would at minimum want a nicer error (because even without ambiguity, the relevant function template code would still error), or even expect the error to be different (non-deleted function definitions of abstract parameter types are not allowed, I would go so far as to say the overload resolution error isn't the real issue).
More specifically, I'd expect the definition-once-maybe-used of:11:11: error: parameter type 'A' is an abstract class:14:9: error: allocating an object of abstract class type 'A'`.
barto behave at least somewhat similar to the definition ofbing(in the case that all thebinglines are uncommented. That is, provide a diagnostic _similar_ tobing's; whereas if all one has isbar(auto)and a call to it, you only getFunnily enough the implementation in gcc 14.1 of the same idea (github mirror: https://github.com/gcc-mirror/gcc/commit/55731b59e6036bd8d262feea54863399229545f4) ends up causing the same / similar low-quality diagnostic / issue.