Santa Cruz is a wonderful location for us to decide weighty matters such as how best to ship a C++ Standard with the overloaded number of issues. Normally a surfing town as I am told, I have not had a chance to even make it to the ocean shoreline as yet even though I am only mere blocks from it. So busy we are that let me waste no more time and recap.

1. P.J. Plauger (or Bill Plauger) has been the convener of the C++ meeting. There was an attempt to stop processing any new features in order to facilitate our promised shipping date for the Standard. The problem is what is new? Some issues are discovered late and are serious if not fixed. Some new issues are truly wish list and should be stopped. Other issues are somewhat in between but need to be weighted with all the other.

The vote that tried to stop all new feature failed probably because of how ambiguous the wording is, in my opinion. The issue isn't about stopping consideration of any new feature, but balancing all features based on their seriousness and only being able to handle a fixed number of them based on resource.

But the problem with that model of triage (which is often done in software industry), is that we are all volunteers and you just can't easily make volunteers do the hard thing, when they would rather do what they like.

The end result is that P.J. Plauger has tendered his resignation as convener. I and many would like to thank him for his service and his guidance which has enabled C++ meeting hostings well into 2011.

2. Both Evolution and Core Committees met in addition to Library. Evolution had to deal with a number of pending additions which had been long promised. The most significant discussion is the proposal to add Asynchronous and Futures to C++. This is a higher abstraction for concurrency that allows independent action with a return value.

This was controversial because there were two leading candidate proposals. The majority of the discussion allowed a unified proposal which offered:

• A restoration of the variadic thread and async functions. This restoration is a consequence of analysis and request of the British Standards Institute.
• A convergence on the "as if a new thread" in the launching of asynchronous work. This change avoids undefined behavior arising from any delay in destroying thread-local variables, but requires careful implementation to avoid excessive overhead.
• Removal of the is_ready, has_exception, and has_value query functions. The presence of these function requires still other functions in the synchronous case. Evolution Working Group direction is that the complexity in interface is as yet unjustified, and prudence dictates a smaller initial interface.
• Unspecified behavior for the use of timed wait functions when the unique_future was created from a deferred async.
• The conversion from unique_future to shared_future will execute any deferred work.
• The use of an enum class to better clarify the launching policy.

The formal motions for C++ Core language which resulted from this include the usual group of defect fixes, numbering into the 70 range. Basically, all Ready and Tentatively Ready issues of
n2962 except issues 799, 812, 861, 919, and 920.

There was also a paper called Reaching Scope of Lambda Expressions

n2998
Current lambdas restrict the referents of a lambda expression to the immediately-enclosing function or lambda expression. This restriction is severe and does damage to the utility of the lambda feature.

For example, a simple matrix multiplication kernal would require two enclosing scopes and there would be no captures. It is essentially equivalent to saying that the body of a nested loop cannot access function parameters.

Much of this is from the paper.

Consider the following function to multiply square matricies.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for ( int i = 0; i < n; i++ ) {
        for ( int j = 0; j < n; j++ ) {
            double t = 0.0;
            for ( int k = 0; k < n; k++ ) {
                t += a[i][k] * b[k][j];
            }
            c[i][j] = t;
        }
    }
    return c;
}

Its rewrite into functions and lambdas, as intended by the adopted N2550, is as follows. Note that the rewrite is approximately the same size.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        for_range( 0, n-1, [&]( int j ){
            double t = 0.0;
            for_range( 0, n-1, [&]( int k ){
                t += a[i][k] * b[k][j];
            } );
            c[i][j] = t;
        } );
    } );
    return c;
}

However this straightforward reformulation is ill-formed as per N2927 wording for 5.1.1 expr.prim.lambda paragraphs 9–12. To make the code well-formed, the function must be rewritten as follows, where inserted text shows new code, which sometimes alter variable references.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows( );
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        const matrix& a1 = a;
        const matrix& b1 = b;
	int& n1 = n;
	matrix& c1 = c;
        for_range( 0, n1-1, [&]( int j ){
            const matrix& a2 = a1;
            const matrix& b2 = b1;
	    int& n2 = n1;
	    int& i2 = i;
            double t = 0.0;
            for_range( 0, n1-1, [&]( int k ){
                t += a2[i2][k] * b2[k][j];
            } );
            c1[i][j] = t;
        } );
    } );
    return c;
}

Such extensive mechanical editing will inhibit use, make errors more likely, and complicate code maintenance. Such editing is properly the domain of the compiler.

A third proposal n2989 "Unified Function Syntax" was not moved after significant discussion on whether it solved significant problem or not especially at this late stage, or just merely being a stylistic wish, especially if you have written large amounts of lambdas with the late specified return syntax and found current syntax ugly.

There was controversy because a previous proposal on auto lambda syntax was moved on the contingency that there would be room to explore a unified function syntax. However, as with all agreement in such a committee, the promise is always to allow the work to go forward with all the resource costs (such as authors and collaborators working together, review committee going over the proposal in this case over eight hours over several day), but there is no promise that it would be accepted. Such was the case, and of course the disappointment of the authors of this paper.

Well, in the next posting I will go over the Library proposal.