This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for constexpr variable templates

> In the 59638 case, the declarations
>   void (*a)(auto);
>   void (*b)(auto) = 0;
> are shorthand for
>   template <typename T> void (*a)(T);
>   template <typename T> void (*b)(T) = 0;
> which, unless there's some constraint with variable templates that I'm not
> aware of, ought to define two variable templates 'a' and 'b' to be
> ptr-to-function-taking-T.  So I think it's correct that the variable
> template stuff should be triggering here.

There isn't, but this interpretation isn't consistent with the use of
auto in variable declarations. For example, this:

  const auto& x = 0;

does not mean:

  template<typename T> const T& x = 0;

So I would be surprised if any of:

  void (*p1)(auto);
  auto (*p2)(int);
  vector<auto> x;

did mean "create a template" instead of "deduce the type of x".

Also, if we did have this interpretation of auto for some (but not
all?) variable declarations, we would have to know to write those as

  void (*p)(auto);
  p<int> = some_f;

since one cannot refer to a template specialization without arguments.

I'm much, much happier if, for variable templates, we always deduce
the type from the initializer.. Besides, that wording (or some
approximation thereof) is already in the TS for concepts. A question
came up during the CWG review as to whether we could declare function
parameters as void (*p)(auto), and EWG said, "sure, go for it". We
also have the ability to declare function parameters as, e.g.,
vector<auto> or pair<const auto&, auto*>. I applied that to variable
templates as well, since it would have been a bit inconsistent,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]