C/C++ and Fortran

Originally posted by: Michael_Wong

Hello all, we are here in Frankfurt as part of the Canadian delegation. This is a momentous meeting.

At this meeting, Concepts, the major feature of C++ 0x, which enables constrained genericity, or template argument prototyping, has been removed from the C++0x draft.

The reason this is big is because many people have worked on this for over 6 years, and it is probably one of the poster child feature for C++0x. Aside from this, Garbage Collection was also removed early in the process, because of fears of its complexity implications. These two features integrate pervasively into almost every area of the standard, are not orthogonal, and have many legacy impacts. The only other major feature that remain, because it has to is concurrency. This last one appears safe, at least.

The reasons for questioning Concepts at this point can be best described by a paper by Bjarne Stroustrup simply called "Simplifying the use of Concepts":

Simplifying the use of Concepts

Bjarne feels that this is a major setback and some feel that this could be patched. Our next chance could be about 5 years, because now it is a redesign, and it is questionable whether the usability, and implementation issues will really be solved.

In the mean time, there will be implications as we make a major change to the latest C++0x draft, likely issue it out for another Committee Draft and National Body Comment. Features that have been accepted since most of Concept entered in the September, 2008 San Francisco meeting may have to be reviewed as they get stripped of Concepts.

Enough about Concepts as I am sure this will not be the last we will hear of it. Lets move on to other things that we have accomplished in this meeting.

1. We plane to submit the Decimal Technical Report to ISO for Technical Report Ballot. This is an important process goal because it enables a specification for using base-10 as the basis for computations, instead of base-2 as we have been using, and continue to use.

Decimal Technical Report

2. For Core language changes, we accepted a number of new papers. The links do not work until the papers are posted about 2 weeks from now.

New wording for C++0x Lambdas (rev. 2)

This paper rewords all of the lambda sections which originally had inadequate wording and examples.

Implicitly-Deleted Special Member Functions.

Now that we have removed concepts, some good things that were brought in by concepts should not be thrown out with the bathwater. This intent of this feature is to ensure that template argument deduction fails when it finds an implicitly-declared special
member function whose definition would fail to compile. The problem came up in the context of concepts, where the
type std::pair<const int, int> was getting an implicitly-declared copy-assignment operator, such that it met the
requirements of the CopyAssignable concept. However, the definition of the copy-assignment operator is ill-formed
(due to the const member), causing unexpected failures. By making this copy-assignment operator deleted, it can no
longer be used to satisfy the requirements of the CopyAssignable concept. Even without concepts, this issue still
comes up with the extended SFINAE rules.

Range-Based For Loop Wording (Without Concepts)

This is another one of those feature that has to be readjusted because of the loss of Concepts. Specifically, range-based for statements will be using argument-dependent lookup of begin and end (which always includes those begin and end functions in namespace std) to provide the iterator to the beginning and ending of the sequence. Specify range-based for statements so that arrays and initializer lists have no dependencies on <iterator>. Refactor <initializer_list> so that it as no dependencies on other headers and includes no other headers.
Specify the library headers that are to #include <initializer_list>.

Pack expansion and attributes (rev. 2)

The aligned_union template in the library was intended to provide simple support for union-like types whose elements may support non-trivial constructors and destructors. When this support was added directly into the language the library template was deemed superfluous, and removed. (This was a TR1 extension, so there are no back-compatibility issues).

However, it has emerged that there remains at least one use case for the feature. When trying to create a 'discriminated union' template using variadic templates, it is not possible to to declare the members of the union via a pack-expansion. This requires a fall-back on an aligned_union like utility.

This would be significantly easier to write if the [align] attribute supported a pack-expansion to return the strictest alignment. This feature is already supported if the types are listed individually, but the grammar does not yet support pack expansion within an attribute. This is seen as the motivating example to extend the attribute grammar to support pack expansion, where the named attribute explicitly documents support.

Explicit Virtual Overrides

We would like to tighten the rules for overriding virtual functions, to detect these problems:

* a base class B has a virtual function f, and the user declares their own f in derived class D, thereby accidentally overriding B::f.
* a base class B has a virtual function f, and the user wishes to override that function in the derived class D, but misspells the name as D::foo.
* a base class B has a virtual function f, and the user wishes to override that function in the derived class D, but inadvertently alters the parameter list.

We are deliberately not solving the problem that a base class B1 has a virtual function f, another base class B2 also has a virtual function f with the same signature, the user derives a class D from both B1 and B2 and declares D::f to override both B1::f and B2::f, one of which may have been inadvertent. (This is sometimes referred to as the Siamese Twins problem.)

The scope of the problem was reduced to the minimal necessary to solve the common real-world problems. This means it does not tackle ideas such as 'final overriders' or function renaming, both of which would be available if a scheme closer to the C++/CLI standard was pursued.

There are also library papers which have been approved. I will describe that in the next posting.