On Thu, Mar 29, 2018 at 6:24 PM, Alexandre Oliva <aol...@redhat.com> wrote:
> On Mar 28, 2018, Jason Merrill <ja...@redhat.com> wrote:
>
>> On Wed, Mar 28, 2018 at 5:06 AM, Alexandre Oliva <aol...@redhat.com> wrote:
>>> On Mar 23, 2018, Jason Merrill <ja...@redhat.com> wrote:
>>>
>>>> On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva <aol...@redhat.com> wrote:
>>>>> + /* Concepts allows 'auto' in template arguments, even multiple
>>>>> + 'auto's in a single argument.
>>>
>>>> I think that's only intended for class templates;
>>>
>>> Aah, that explains a lot! Dang, it was so close!
>>>
>>> It actually makes sense; was there any discussion about standardizing
>>> this, with reasons to reject this construct, or is it just that we
>>> aren't there yet? I wouldn't be surprised if it were to appear in some
>>> future version of C++.
>
>> If what were to appear?
>
> auto in explicit template arguments for template functions too.
>
>> We only want 'auto' in places where it could be deduced, and there's
>> no way in [temp.deduct.type] to deduce from explicit template
>> arguments to a non-type template.
>
> Well, it could be standardized in some way, e.g. autos could be deduced
> from types of function arguments and expected return types, just like
> function overloads, very much like typename template arguments are
> currently deduced. Having all explicit autos resolved would be a
> requirement for a specialization to be viable. Consider:
>
> template <typename A, typename B, typename C> A foo(B b, C c);
>
> ...
>
> int x1 = foo("", 0); // ok, all args deduced
> int x2 = foo<int>("", 0); // ok, A is explicit, B and C are deduced
>
> int x3 = foo<int, auto, int>("", 0); // B could be deduced as in x2
> int x4 = foo<auto, auto, auto>("", 0); // all args deduced as in x1
>
> auto x5 = foo<auto>("", 0); // deduction of A from context fails
>
> Cases in which auto appears in the top-level are the trivial ones, that
> our type deduction machinery could support right away (it has to; it's
> the same as deducing any typename argument left out).
>
> More involved cases, in which auto appears other than at the top level,
> could still be deduced in general, though we would need some more
> implementation work to get them right:
>
> int *x6 = foo<auto *, auto *, auto>("", 0);
> // deduced: int const char int -> calls foo<int*,const char *,int>
>
>
> I seems to me it would be a natural extension to the existing draft
> specs; I guess the most common use would be to just tell the compiler to
> figure out one specific template argument, when you only wish to
> explicitly specify another after that: foo<auto, int>
I suppose that's possible. Nobody has suggested such a thing to the
committee, however.
>>> Is this (in the patch below) the best spot to test for it?
>
>> This seems like a plausible spot, but is there a reason not to check
>> in cp_parser_template_id?
>
> AFAICT we wouldn't always know, within cp_parser_template_id, whether
> the id is a type or a function.
True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
IDENTIFIER_NODE. Looking at tsubst_copy_and_build, I see that we
don't call finish_id_expression when substituting such a
TEMPLATE_ID_EXPR. So maybe lookup_template_function and
lookup_template_variable are the right places for this test.
Jason
