We have had a huge success in terms of participation in the standard meeting with one hundred people working during a six days week starting at 8:30 and with after-dinner evening sessions. Really impressive work from many people. For further information on the C++ Committe you can get a lot of useful information at isocpp.org.
Other committe members write excellent reports on every meeting, and I always recommend to read the really good trip reports from Herb Sutter. Here you have the latest one.
So I thought I could right a different view on a couple of tiny details. I will give my very personal view on two issues one that got accepted (generic lambdas) and one that got rejected (digit separators).
Concepts lite and generic lambdas
The committee decided that concepts lite required to be in a separate Technical Specification (TS) and not in the standard to give opportunity for fruther experimentation. I tend to agree with this view, although there is a working implementation.
However, the committe decided to put generic lambdas in the International Standard for C++14. I like generic lambdas a lot. They are great! I have already felt the need of generic lambdas in some of my current implementations. But I feel that the safest path would be to put them in the same TS than concepts lite.
Although I know it is unlikely, it could happen that later in the process we could find that we wanted a tighter integration of generic lambdas and concepts. I hope we do not regret of our dicision here. I agree that the risk is low, but it is still a risk.
Moreover, I think that having generic lambdas in a TS rather than in the IS, would be the safest path, and implementors still may deliver their products with TS implementations.
The recurring digit separators discussion
We discussed a lot of options about digit separators. The idea behind is to make easier writing long numeric literals so that they are more readable and code is easier to maintain.
Today if you want to use the speed of light in your code you do something like:
constexpr double speed_of_light = 299792458;
With the digit separator proposal that could be written:
constexpr double speed_of_light = 299_792_458;
Unfortunately this proposal did not pass, because there was an argument about its interaction with UDL (user defined literals). The case that arised during the discussion was:
x = 0xFF_EB; // 255 Exabytes or 0xFFEB?
I do not think that writing Exabytes in hexadecimal is so common to justify not making a service to user communities that use long literal numeric constants. But I may be wrong.
