> 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 template-ids: 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, otherwise. Andrew
