This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Voted into WP at the October, 2006 meeting.]
Mike Miller:In fact, now that I've looked more closely, that appears not to be thecase. (At least, it's not the error I get when I compile his example.)Here's a minimal extract (without the inflammatory using-directive :-)that illustrates what I think is going on:
template <typename _Iterator> struct iterator_traits { typedef typename _Iterator::difference_type difference_type; }; template <typename _InputIterator> inline typename iterator_traits<_InputIterator>::difference_type distance(_InputIterator, _InputIterator); double distance(const int&, const int&); void f() { int i = 0; int j = 0; double d = distance(i, j); }What happens is thatiterator_traits<int>is instantiated as part oftype deduction for the function templatedistance, and the instantiationfails. (Note that it can't be instantiation ofdistance<int>,as I had originally posited, because in this case only a declaration, not adefinition, of that template is in scope.)
John Spicer: Yes, I believe that is what is going on.
Mike Miller:I seem to recall that there was some discussion of questions relatedto this during the core meetings in Oxford. I think Steve Adamczyksaid something to the effect that it's infeasible to suppress allinstantiation errors during template type deduction and simply callany such errors a deduction failure. (I could be misremembering, andI could be misapplying that comment to this situation.)
John Spicer:Regardless of other conditions in which this may apply, I don't thinkit would be reasonable for compilers to have to do "speculativeinstantiations" during template argument deduction. One classinstantiation could kick off a series of other instantiations, etc.
Mike Miller:I don't see anything in the Standard that tells me whether it'slegitimate or not to report an error in this case. I hope John oranother template expert can enlighten me on that.
John Spicer:My opinion is that, because this case is not among those enumeratedthat cause deduction failure (rather than being ill-formed) thatreporting an error is the right thing to do.
Mike Miller:I am still interested, though, in the question of why13.10.4 [temp.over] says thatviable function template specializations are instantiated, even if theyare not selected by overload resolution.
John Spicer:I believe the wording in13.10.4 [temp.over] is incorrect. I researched this andfound that a change was made during the clause 14 restructuring thatwas incorporated in March of 1996. The prior wording was "the deducedtemplate arguments are used to generate a single template function".This was changed to "deduced template arguments are used toinstantiate a single function template specialization". I believethis resulted from what was basically a global replace of "generate"with "instantiate" and of "template function" with "function templatespecialization". In this case, the substitution changed the meaning.This paragraph needs reworking.
Proposed resolution (April, 2006):
Change 13.10.4 [temp.over] paragraph 1 as indicated:
...For each function template, if the argument deduction and checkingsucceeds, thetemplate-arguments (deduced and/or explicit) are used toinstantiatesynthesize the declaration of a singlefunction template specialization which is added to the candidatefunctions set to be used in overload resolution. If, for a givenfunction template, argument deduction fails, no such function is addedto the set of candidate functions for that template. The complete setof candidate functions includes all thefunction templatesinstantiated in this waysynthesized declarations and allof the non-template overloaded functions of the same name. Thefunction template specializationssynthesizeddeclarations are treated like any other functions in the remainderof overload resolution, except as explicitly noted in 12.2.4 [over.match.best].