http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-23 02:03:41 UTC --- (In reply to comment #12) > Manual said: > g++ could also specify which ones are viable candidates, and which ones are > not > even viable, and for the ones not viable, explain why. None of the functions are viable, because 'newNode' is ambiguous. So your suggestion seems to be: request for member is ambiguous Overload 1: not viable, reason: ambiguous. Overload 2: not viable, reason: ambiguous. Overload 3: not viable, reason: ambiguous. Overload 4: not viable, reason: ambiguous. Overload 5: not viable, reason: ambiguous. Overload 6: not viable, reason: ambiguous. rather than what we have now: request for member is ambiguous Overload 1 Overload 2 Overload 3 Overload 4 Overload 5 Overload 6 [unhelpful nonsense about expected primary expression] I think the second one is better (apart from the primary expression part) Or maybe you could have: request for member is ambiguous Overload 1: not viable, reason: ambiguous. Overload 2: not viable, reason: ambiguous. Overload 3: not viable, reason: ambiguous, and wrong number of args Overload 4: not viable, reason: ambiguous, and wrong number of args Overload 5: not viable, reason: ambiguous, and wrong number of args Overload 6: not viable, reason: ambiguous, and wrong number of args I don't think that helps - changing the number of arguments wouldn't make the testcase compile. Resolving the ambiguous lookup would.
