This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts
On Mar 28, 2018, Jason Merrill <jason@redhat.com> wrote:
> On Wed, Mar 28, 2018 at 5:06 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Mar 23, 2018, Jason Merrill <jason@redhat.com> wrote:
>>
>>> On Fri, Mar 23, 2018 at 3:38 PM, Alexandre Oliva <aoliva@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>
>> 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. It seemed to me that we could
tentatively parse it as a type, and then reuse the same preparsed id as
a function. If I were to check the argument list at that point,
assuming one or the other, we might reject something we should accept or
vice-versa, and we wouldn't revisit that decision. I'm not saying I
tried and observed this, it is just a hunch based on observing how the
foo<auto>() expression was parsed and reparsed, and on extrapolations
from the preparsing of qualified names that I've recently had a close
encounter with ;-)
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer