Re: [c++-concepts] constrained friends redux

[Andrew Sutton <andrew dot n dot sutton at gmail dot com>]

>> +          // Do not permit the declaration of constrained friend
>> +          // function declarations. They cannot be instantiated since
>> +          // the resulting declaration would never match the definition,
>> +          // which must be a non-template and cannot be constrained.
>
>
> You're in the template-id code here, so "must be a non-template" is
> confusing:
>
> template <class T> void f();
>
> struct A {
>   friend void f<int>(); // matches a template
> };
>
> Perhaps you mean that it must match a fully-instantiated function, so any
> constraints on the templates were considered during
> determine_specialization.

This seems like a simple comment fix, but there's a longer explanation
of what I want (see below). Would this be more appropriate?

  // Do not allow constrained friend template specializations.

The intent is stronger than to say it must match something. I don't
want to allow any declarations of the form

template<typename T>
struct X {
  friend void f<>(T x) requires C<T>; // Error.
};

This should never even get to determine_specialization since the
original declaration is never actually pushed.

We could use those constraints to match the specialization to one of
several constrained overloads, as you mentioned earlier, but I'd
rather avoid that for now. Solving that problem in general would
require that we allow constrained (explicit) specializations and
define a method of matching instantiated constraints to dependent
constraints, and that we do so as an alternative to the usual
constraint checking during template argument deduction.

Maybe it's a useful feature, but it's really hard to gauge how much
use it would actually get. We can always revisit that in the future.
Somebody else can write that paper :)

Andrew