Highlights from the current ISO proposals.

I thought I'd take some time to highlight some of the interesting proposals I read today after having stumbled on a link to them:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/#mailing2012-11

I've been waiting over four years for Concepts to become standard. It started to feel like Stroustrup had given up on the idea, but luckily N3351 (pdf) by him and Sutton shows there has been progress. It's not honestly the most fascinating read, but when concepts are finally approved, they will improve on tag dispatch. Since a lot of my code currently uses this technique, I look forward to being able to replace it.

Really, really looking forward to it. We are forced to invent such witty ways of expressing generic functions with enable_ifs and partial template specialization, delayed instantiation, but we could just define some abstract principles about types and use those, abondoning all of it. (I do want to point out that ConceptGCC and ConceptClang do exist.)

N3418 (pdf) talks about polymorphic lambdas and N3386 talks about using auto as the return type for regular functions. The latter contains this line, which I think says it all:

    "template <class T> auto g(T t) { return t; } // return type is deduced at instantiation time"

N3328 talks about "Resumable Functions" (continuations) and introduces a few new keywords to facilitate the tricky syntax.

The Boost::option library is attempting to get in via N3406. The idea of Boost's option is very like that of Maybe in Haskell.

N3449 proposes a "Open and Efficient Type-Switch". Since this is a really foreign concept to C++, it'll be interesting to see what comes of it.

N3404 and N3505, both by a Mike Spertus, show some impressive "tidbits" with tuples and templates. The latter especially spoke to me; he shows an example of a templateted type, Foo, holding a function, F, and the example includes this:

    Foo<???>( []{ ... } )

What's the type of F? Lambdas have implementation-defined types, so we just don't know. He argues that the compiler can deduce the type here. We should be able to write Foo([]{...})!

I'd like to extend this idea. If I wrote a function g(f,x)=f(x,x), then I'd like g(Foo,x) to equal Foo(x,x) and g(std::pair,x)=std::pair(x,x). As it is, I end up writing a function that constructs a Foo and call it foo.

Unpacking tuples into functions (i.e. apply(f,tuple(1,2,3))=f(1,2,3)) has had some interesting discussion over the past few months. Solutions currently include constructing a variadic type of indexes and std::get. N3326 asks why not do something much more general? I really don't want to do it injustice by trying to explain. It's a great read!


There is plenty more I'm not mentioning: parallel programming, filesystem library, reflection, URI's, std::range, and modules. The proposals of today seem very different than the proposals of when I started programming. C++ feels like a language with a much stronger foundation, which lends itself to expansion, inspiration, and innovation. What will this round of standardization bring?