[C++ PATCH]: Incomplete explicit args

[Jason Merrill]

On 28 Jul 2003 09:01:20 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> On Mon, 2003-07-28 at 04:18, Nathan Sidwell wrote:
>> Hi,
>> this patch fixes a regression with explicit specialization. If
>> fn_type_unification is given a set of (incomplete) explicit args, it will
>> tsubst that into the function type, before proceeding with deduction.
>> (14.8.2/2 3rd bullet tells you to do this). The bug is that the
>> explicit args need not be the complete arg list and in the above
>> tsubsting, something could refer to an unspecified arg. There is code
>> in tsubst which deals with this for a template_parm, but that has become
>> insufficient now that we deal with non-dependent exprs better.
>> The test case contains a declaration
>> 	template <int n, int x> R<Trait<n,x>::m> f(A<x>);
>> and a use as
>> 	ptr = &f<1>;
>> that has to do unification. We tsubst the single explicit arg
>> into the scope ref Trait<n,x>::m in the return type. That occurs
>> when processing_template_decl is false so happens inside
>> tsubst_qualified_id and ends up looking inside of the partial specialization
>> Trait<1,x> for an (unfound) m. Thus the substitution fails.
>
> Interesting.
>
> I looked at this in passing a few days ago.  I would *like* the
> invariant to be that you *never have to substitute unless you have a
> full set of arguments*.  I believe that this requirement in
> [temp.deduct]:
>
>        [temp.deduct] 
>        
>        When all template arguments have been deduced, all uses of
>        template parameters in nondeduced contexts are replaced with
>        the corresponding deduced argument values.  If the
>        substitution results in an invalid type, as described above,
>        type deduction fails.  */
>
> when confronted with an incomplete set of arguments (as you show above)
> is the only place where the standard suggests otherwise.
>
> I wonder if we could convince the committee to allow deduction in this
> case.

I don't see how that passage suggests otherwise.  The preceding sentence
does, however:

The resulting substituted and adjusted function type is used as the type of
the function template for template argument deduction.

which to me means that when we see f<1>, we use "R<Trait<1,x>::m> f(A<x>)"
in further deduction.  That seems pretty clear to me.  What alternative are
you suggesting?

We shouldn't look up m because it is still dependent.  uses_template_parms
is an approximation of the dependency check; I think we should be able to
do better by making the substitution work more like parsing.

Jason