The Wikipedia article quotes this usage:

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

Apparently you'll only need it when the return type would depend on the types of the arguments.

Can't you do that already with templates without that syntax though?

It seems like quite a stretch to me.

Please give a useful example of how it is useful then. The example anonymous gave is quite a stretch, how often does your return value depend on mroe than one template parameter?

What's POD? The closest definitions I could find were Portable On Demand and Prince Of Darkness.

Plain Old Data Structures? That's PODS.

Any of these would also do the job I am sure, But Fortran 2003 comes to mind.

C/C++/C++0x aren't in that list at all.

I remember a thread in Gamedev where someone wanted to make Vector<int> + Vector<double> return Vector<double> (or generally Vector<the_type_that_the_result_is_promoted_to>). It can be simulated (at least to some extent) with some metaprogramming, but C++0x would allow this quite simply.

It is probably not a very practical example, just something that a zealous library-writer thought would be cool.

Another thing is that perhaps it can provide a small shortcut to things that are tedious to type:

template <class T>
typename std::vector<T>::const_iterator foo(const std::vector<T>& vec);

template <class T>
auto foo(const std::vector<T>& vec) -> decltype(vec.end());

Ok, not that much shorter, and probably not entirely clear (This, I believe, would actually be simplified by template typedefs.)

It is quite likely that its main usefulness would be in template metaprogramming or with some new features like variadic templates.

In practice it's happening every time you add values of different type: they are promoted to something but you'll just assign (cast) them to some type to store the result.

-----

If I'm not mistaken, all the features don't come from some committee. Real programmers like you and me can (could) make suggestions, and then the committee would discuss which are actually good ideas, which are feasible to implement, which would break existing code etc.

Someone who wants to do this should re-think their coding habits.
The proper solution is a utility function that takes one Vector<int> and one Vector<double> and returns a Vector<double>. Even with vectors of the same contained type, operator+ isn't intuitive - addition could be understood to mean any of:
- append all elements of A to C, then append all elements of B to C, then return C
- append all elements of A to C, then append all elements of B that are not elements of A to C, then return C
- for each element in A, find the element at the same position in B, calculate their sum, and append it to C; then return C

Facilitating something like this isn't cool, it leads to the kind of unmaintainable convoluted code the C folks are so proud of, or the kind of template abuse some C++ programmers seem to love so much.

The question was about the geometrical vector, not the container.

I understand that it was an entirely theoretical discussion, since in practice it probably won't be that necessary, but C++0x would allow one to implement it like this:

template <class T, class U>
auto operator+(const Vector<T>& a, const Vector<U>& a) -> Vector<decltype(a.x + b.x)>
{
    return {a.x + b.x, a.y + b.y}; //another advantage of new constructor syntax?
}

Right now what you could do is:

//lots of metaprogramming here

template <class T, class U>
Vector<promote<T, U>::type > operator+(const Vector<T>& a, const Vector<T>& b)
{
    return Vector<promote<T, U>::type >(a.x + b.x, a.y + b.y);
}

Or perhaps support just a few vector types (who needs many different types anyway) and define the int + int -> int and double + double -> double versions (if the implicit conversions work, if not also int + double -> double and double + int -> double).

But this is against convention. If the types support +=, they should also support equivalent +

Except the calls would be rather awkward:

c = Vector<double>::add(a, b);

If one is writing a library to be used often, I'm all for the one-time investment to make things more pleasant for the end user.

I've never said that the whole thing is meant to be practical... but isn't it nice if you can do it simply?

Todays C++ also discourages it.

In practice it seems that it can simplify your prototypes (a bit like I showed above, but instead with a out-of-line member function definition involving nested types as the return value) and it may have something to do with SFINAE (well, not my line).

I guess it is also a compromise with compiler implementators (if I'm not mistaken the standard committee is trying to avoid repeating the "export" mistake - a very useful feature which practically all compiler writers found too difficult to implement).