Re: c++/3708: Zealous template expansion

[P Hornby <p dot hornby at ned dot dem dot csiro dot au>]

Further to the issue of allowing uneeded templates onto candidate lists.
Take for example the code in build_new_function_call (gcc/cp/call.c)
.........

      for (t1 = fn; t1; t1 = OVL_CHAIN (t1))
	{
	  tree t = OVL_FUNCTION (t1);

	  if (TREE_CODE (t) == TEMPLATE_DECL)
	    {
	      templates = tree_cons (NULL_TREE, t, templates);
	      candidates = add_template_candidate
		(candidates, t, NULL_TREE, explicit_targs, args, NULL_TREE,
		 LOOKUP_NORMAL, DEDUCE_CALL);  
	    }
	  else if (! template_only)
	    candidates = add_function_candidate
	      (candidates, t, NULL_TREE, args, LOOKUP_NORMAL);
	}
..........

if there is both a template function bob( T & ) and an explicit function
bob(const char *) at
global scope, and a call of the form

bob(apple) with apple a const char *, then the above code will add both

bob(const char *) and bob( T& ) [ T = const char *] to the candidate
list.
Sure, that's OK, the subsequent joust eliminates the latter contender.
Problem is
that add_template_candidate has already put bob( T& ) [ T = const char
*] onto
pending_templates. As a result, this template is expanded by
external-templates, even if
not needed. 

Am I the only one that thinks there could be a problem with handling
templates like this?

Surely the push to pending_templates should be after the joust, or
better still,
the candidate declarations ordered and scanned inheritance first,
partial ordering second.....
even in the interest of efficiency alone!
Then the more general, or (possibly) base class templates could be
prevented from
being added to the candidate lists in the first place (unless needed).

In similar code, in the method call routines, bfs_walk tries to do this
to a certain extent
with the class heirarchy ordering, and name marking, but gets defeated
by the template name
being different to its required instantiated name....and the name of the
explicit method...yuko!

Is depricating external-templates really addressing these issues? 
Will the current approach eventually bite harder somewhere else?