Let me preface this comment by saying that I’ve read all posts with great interest. This is an excellent blog. I’ve learned a great deal from the posts and comments. I’m very excited about C++0x. Type inference, range-based for loops, closures, and initializer lists can’t come soon enough!

I do have a couple of gripes though that I wanted to rant about. My biggest issue is probably the alternate function syntax. The justification for it seems to be as follows:

template<typename LHS, typename RHS> 
  decltype(lhs+rhs) AddingFunc(const LHS &lhs, const RHS &rhs) {return lhs + rhs;}

This is apparently not legal since lhs and rhs have not yet been defined; so the proposed solution is:

template<typename LHS, typename RHS> 
  [] AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}

When I first read this, I was baffled. Really? Why not just go with the former (saner) syntax and require the compiler to “look ahead” in the function declaration? It’s all one statement anyway! Just look at the function parameters first, then look at the return type. Who cares that it’s typed in the reverse order?!

This seems akin to the vector<list<int>> issue, which was resolved by having the compiler do “the right thing”(tm) instead of needlessly burdening the programmer. In fact, this is even less of an issue in the code above, since there is no ambiguity. The former statement is sane, while the latter is verbose and adds unneeded complexity to an already complex language. Just great. We take a step forward with uniform initialization, and take one step back with a new way to declare functions. Lovely. Here’s a crazy idea: why not force the few compiler folks to do a little bit of extra work “looking ahead”, instead of forcing the rest of us to suffer the new verbose function syntax until it’s inevitably “fixed” 7 years down the road; much like the vector<list<int>> non-issue.

My rant got a bit out of hand length-wise, so I’m going to submit the second part on concepts separately. In the meantime I’d love to hear what other folks think of the new function syntax.

The problem with this approach is that the compiler can’t in general know whether the object has gone through the change or not (because it happens at run-time):

if(some_user_input())
  x.normalize();
 
ThisOnlyTakesNormalVectors(x); // Call succeeds?

However, using move semantics and clever compiler optimisations (such as RVO), you might get away with code like below, with little or no overhead (and no movement of data):

Vector3Impl x(1, 2, 3);
 
Vector3Normalized y=x.normalize();
 
ThisOnlyTakesNormalVectors(y); // Ok

Suppose you have a class that satisfies the “Vector3″ concept, which is a 3 dimensional vector. However, there is another concept called “NormalVector3″ which has the expected length == 1 axiom and it doesn’t let you use +=, -=, etc. to vector addition/subtraction or any other operation that might ruin the “normalness” of the vector.

Now suppose you create an instance “x” of the “Vector3Impl” implementation class. “Vector3Impl” satisfies the Vector3 concept. Here is a declaration:

Vector3Impl x(1, 2, 3); // Not a normal vector in general, but it could be!

The thing is, once you call:

x.normalize();

the instance is now guaranteed to be a normal vector, except the method has no way of communicating this to the compiler without creating a new object of a different type that has different semantics. Since the compiler doesn’t know this, if you had a concept-overload like this:

template <NormalVector3 N>
void ThisOnlyTakesNormalVectors (const N&);

as far as I understand, you cannot pass x to it because x has the original type Vector3Impl, which satisfies the concept Vector3 and not NormalVector3. By the way, perhaps that is what the other poster meant when they referred to “concept_cast”?

Calling normalize changes “*this” but you do not want it to change “this” or return a new object. Instead, you want to say that x has the same type and does move in memory at all, but at compile time conforms to a different semantic concept, that of being a normal vector.

I wouldn’t use vectors and matrices just for exposition; they occur everywhere in scientific computing, where performance is critical and you can’t copy anything. It would be nice to be able to say “once I modify this l-value, I can now guarantee (or drop a guarantee) that an object belongs to certain overload set, which will change how it is treated by the compiler after the modification point”.

For example, you tack some syntactic information onto the Vector3Impl::normalize method, so that upon returning it mutates (in some sense) the concept overload resolution of x, so that it can now be passed into the function “ThisOnlyTakesNormalVectors”.

I don’t know what to call this, or if its a very bad idea in the general case. It is like “instance concepts” instead of “type concepts”. It’s different than dynamic typing because the methods explain at compile time how they are changing the concept of the mutated object.

What were the reasons for rejecting contract programming? It is a commonly used, well understood and very useful programming technique that could gain a lot from language support. I can’t see them as a replacement for axioms. They are independent features that could complement each other very well.

I totally agree. But looks like polymorphic lambdas are to appear in the next Standard (hope it’s not C++2x)?

Hi Brendan,

Thanks for asking.

I always get nervous around questions about what “anyone in the real world cares about,” since the definition of “real world” is subjective, and although everyone thinks they know what “average C++ programmers” care about, we don’t have any data.
That said, in the “real world,” some people:

• would like to write generic programs straightforwardly, without resorting to hacks like tag dispatching
• would like to know that they have documented all the requirements of their templates without resorting to hacks like concept archetypes; instead they’d like the compiler to check for them automatically
• would like to have their templates completely checked at the point of definition (similar to above point).
• would like to be able to use independently-developed types with generic libraries without tedious type wrapping

That seems to be satisfied well enough by the simple syntax checking case. Heck, static_assert seems like it does that.

Even if you just care about better error messages for uses of templates, using static_assert to accomplish the same quality of error messages as you could get from concepts would be a lot of work.

I saw in some older specs that you could specialize templates based on concept? Oh man, that was ridiculous. Who cares? How am I actually going to use that?

You can write templates that are optimized based on the concepts satisfied by their template parameters. We have plenty of examples of that today (e.g. binary_search works on forward iterators, but is faster on random access iterators) , but today’s examples use the hacks mentioned earlier.

Then were going to need some kind of concept_cast just to use the libraries.

Not sure what you have in mind when you say “concept_cast,” but I don’t think anything like that is needed.

I don’t really get what you mean by by constraining boost lambda. I never used that library since it was so ridiculous.

Leaving aside the evil late_check feature, any template you want to use inside concept-constrained code also needs to be concept-constrained. So if you want to use a library like Boost.Lambda (or some features of Boost.Bind)—and many people do—in constrained code, that library had better also be constrained.

It seems especially pointless now that C++ has actual lambda’s.

C++0x lambdas are actually a big disappointment to me, because unlike Boost.Lambda they’re not (compile-time) polymorphic. I don’t think

[](foobar const& x, baz const& y) { x +y }

(or however it’s spelled) can compete with

_1 + _2

for usability or readability.

If you are arguing for more advanced concept features (I’m kind of unsure) maybe you could give a concrete example of how they would be used in actual application code? Right now the only use I see for concepts is that it saves typing over using static_assert.

I’m not arguing for more advanced concept features, but if you want some examples I suggest perusing the ConceptC++ documentation.

Example:

concept Callable<typename F, typename... Args> {
  typename result_type;
  result_type operator()(F &, Args...);
  result_type operator()(F &&, Args...);
}
struct A {};
struct B {operator A() const;};
struct C {operator B() const;};
struct T {
  void operator()(A);
};
 
template<typename F> requires Callable<F,B>
void foo(F & f) {
  f( C() );
}
 
void bar() {
  T t;
  foo(t);
}

As far as I can tell this is another hole with the current rules. The function signature in Callable<F,B> suggests that we can invoke a function with a parameter that is implicitly convertible to B. This includes an object of type C. But C is not directly convertible to A. We would need two user-defined conversions to invoke T::operator() with an object of type C. This seems to result in another late instantiation error. On the other hand this function requirement implies an expression that is guaranteed to be well-formed: We can invoke the function with a parameter of type B that is an rvalue if B is not an lvalue reference. This is an inconsistency. The problem here is that the constrained template doesn’t know anything about whether the function takes actually a B or an A — or a rvalue reference to a B in which case we don’t need B to be MoveConstructible. The actual parameter type is “hidden” but we need to make sure that the object we pass is convertible to this hidden parameter type. But since it’s “hidden” we can’t express such a requirement.

If we modified the rules for (1) to match the rules for (2) this constrained template would not type-check because Callable<F,B> would only guarantee that an F is callable with an rvalue of B as parameter. We should have written Callable<F,C> instead to make the constrained template well-formed. We just can’t use it with F=T because Callable<T,C> is not satisfied.

What I’m saying is that I don’t like the inconsistency between the checking rules for (1) and (2). Maybe function signatures are not the right tool for expressing syntactical requirements. Maybe it’s worth trying “expression requirements” again.