Today I attended two excellent talks by Bjarne Stroustrup at the ACCU Conference 2013. The first was an inspiring explanation of the recent C++11 standard, and the second, “C++14 Early thoughts” was an exciting description of some of the features that might go into the next standard.
One of those features, which Bjarne called “Terse” Templates, might be a good idea, but the syntax Bjarne proposed seems like a bad idea to me, because it leaks unwanted names into the namespace containing the function you are writing.
Allow me to explain.
Background – Concepts Lite
I attended another excellent talk before Bjarne’s, called “Concepts Lite-Constraining Templates with Predicates” by Andrew Sutton, introducing “Concepts Lite”, which is an attempt to salvage a manageable language feature from the very large “Concepts” feature that failed to make it into C++11.
My (so far very basic) understanding of Concepts Lite is that it is a way of defining conditions that state whether a template will be expanded for a given type.
So, in C++11 (and C++98), we can declare a (stupid) template function like so:
template<typename ListOfInt>
int first( ListOfInt& list ) { return list.size() > 0 ? list[0] : 0; }
The code in this function template assumes that list has a size method, and an operator[] method. We tried to “suggest” this, by naming our template parameter ListOfInt, but the poor programmer may not realise exactly what we meant.
If we do the wrong thing, and try to use the first function with an int argument:
int i = 3;
first( i );
It goes wrong, because ints don’t have a size method:
In function 'int first(ListOfInt&) [with ListOfInt = int]':
error: subscripted value is neither array nor pointer
error: request for member 'size' in 'list', which is of non-class type 'int'
This error is not too obscure, but in complex cases the errors can be extremely long, and point to problems that appear to be unrelated to the code we are writing.
Really what we want to know is that int is not a ListOfInt.
Concepts Lite give us the ability to define what a ListOfInt means, and only expand the template for types that match that definition.
In our example we would do something like this:
template<typename ListOfInt> requires SizeAndIndex<ListOfInt>()
int first( ListOfInt& list ) { return list.size() > 0 ? list[0] : 0; }
(There is actually a neater syntax, but we’ll do it like this for now because we need the more verbose form later.)
What this means is that this template function will only be expanded for types that satisfy the constraint.
The definition of SizeAndIndex is outside the scope of this article – it allows us to check whether types satisfy some conditions. In this case we assume it checks that the type contains the methods we use.
Now when we do the wrong thing:
int i = 3;
first( i );
We get a simple error message, that properly tells us what’s wrong:
error: no matching call to ‘first(int list)’
note: candidate is ‘first(ListOfInt& list)’
note: where ListOfInt = int
note: template constraints not satisfied
note: ‘ListOfInt’ is not a/an ‘SizeAndIndex’ type since
note: ‘list.size()’ is not valid syntax
(The above is fiction, but Andrew assures us he gets real errors like this with his prototype.)
So Concepts Lite gives us the optional ability to check that our template parameters are what we expected them to be, giving a decent error message, instead of waiting for something to fail much later when we compile the instantiated template.
So far so utterly cool. (And, in my ill-informed opinion, the only bit of Concepts I really wanted anyway.)
There’s more information on this feature here: Concepts Lite: Constraining Templates with Predicates and here: Concepts-Lite.
Constraints on multiple types
The Concepts Lite feature as proposed allows us to specify constraints that describe how multiple types relate to each other, by doing something like this:
template<typename Victim1, typename Victim2> requires Lakosable<Victim1, Victim2>
void lakos( Victim1 a, Victim2 b );
Here the Lakosable constraint can specify conditions that describe how the two types relate to each other, for example that Victim1::value_type is equal to the type of Victim2.
This is very good.
Now, the bit I want to argue against.
“Terse” Templates – the syntax I don’t like
Bjarne gave us an example of the std::merge function, which has lots of arguments, and very complex constraints on them. He showed us that these could all be nicely wrapped into a single Mergeable constraint (similar to the Lakosable constraint above) but he argued that there was still too much repetition. The repetition comes from the fact that several functions in the standard library have the exact same template parameters, with the exact same constraints on them, and that you have to mention the whole list of template parameters twice: once after the template keyword, and once in the requires condition.
This led him to look for a terser syntax.
So, he proposed a modest new construct that looks like this:
using Lakosable{Victim1,Victim2}; // (1)
that allows a radical departure from everything that has gone before in terms of declaring templates. After we’ve made the declaration (1), we can declare the exact function we declared above with this little line:
void lakos( Victim1 a, Victim2 b ); // (2)
The using declaration in (1) makes the names Victim1 and Victim2 available in the current namespace, and gives them special powers that mean functions taking parameters of type Victim1 or Victim2 are automatically function templates, even though the template keyword is nowhere to be seen.
There was some resistance in the room to this proposal. Most of it focussed on (2), and the fact that templates were being declared without it being visible because of the lack of the template keyword.
I’m actually ok with (2). In fact, my ficticious programming language Pepper (which represents everything I think is Right in programming languages) provides a feature very much like this – all non-definite parameter types act as “implicit” templates in Pepper (see “implicit_templates.pepper” on the Examples page).
Bjarne made a reasonable defence of (2), arguing that we often want new features to be “signposted” by new keywords (he cited user-defined types as an example – apparently some people wanted to require “class MyClass” instead of just “MyClass” every time we referred to a user-defined type) but later when they are familiar we want less verbose syntax. (Presumably the “new” feature he was talking about here is templates.)
My problem is with (1).
As my neighbour in the talk (whose name I missed, sorry) pointed out, what (1) does is dump 2 new names Victim1 and Victim2 in the namespace containing the lakos function template.
No-one wants these names.
In fact, why are we doing any of this?
The sole purpose of the exercise is to constrain the lakos function template. Why is the result putting 2 names into the namespace?
More seriously, in the case of the standard library, these names will go into the std:: namespace, and there could easily be clashes. If the std::merge function uses the name For for one of its template parameters (a Forward_iterator), and std::copy wants to use one with the same name, but with different constraints, it will override the definition of For.
I.e. If we do this:
namespace std {
using Mergeable{For,For2,Out};
// define std::merge
}
// and somewhere else:
namespace std {
using Copyable{For,Out};
// define std::copy
}
then the (useless) value of std::For will be different depending on the order in which we import the header files.
I Think
I think.
Please correct me if I’m wrong.
Conclusion
If I’m right, this all seems bad and Wrong.
What was wrong with:
template<typename Victim1, typename Victim2> requires Lakosable<Victim1, Victim2>
void lakos( Victim1 a, Victim2 b );
anyway?
Share on Mastodon