The paper introduction is misleading: the idiom is actually
template <typename T, T t>
It denotes a template which depends on a type T
and a value t
of that type. The notation is a bit heavy since in most situations the type could be deduced from the value itself.
E.g.
// the current definition notation
template <typename T, T t> void f() { t.f(); };
//// the proposed definition notation
//// the parameter t depends on an implicit typename parameter T
// template <using typename T, T t> void f() { t.f(); };
struct foo {
void f(){
// some computation
}
};
foo bar;
int main(){
// the current instantiation notation
f<foo,bar>();
//// the proposed instantiation notation
//// we know that bar is of type foo, so we don't need to specify it
// f<bar>();
}
The proposal is about introducing a bit of "syntactic sugar" to make the notation easier to write.
Also, the example given above is trivial in its description (and possibly wrong, since template parameters need to be constexpr
), but the paper describes several situations where the current notation can become quite hairy, reducing readability and overall ease of programming.