Title: Standards Report

Author: Martin Moene

Date: 04 January 2015 21:39:25 +00:00 or Sun, 04 January 2015 21:39:25 +00:00

Summary: Mark Radford brings the latest news from C++ Standardisation.

Body: 

Hello and welcome to my latest standards report.

In my last report I mentioned that the next ISO C++ meeting would be held in Urbana-Champaign, IL, USA, 3rd–8th November. Unfortunately my deadline for that report was a couple of weeks before the meeting, which meant I couldn’t give it any coverage. Therefore I’ll be covering it in this report. Also there are two new mailings since my last report i.e. the pre- [1] and post-Urbana [2] mailings (the timing was such that when I actually wrote my previous report, even the pre Urbana mailing wasn’t yet published).

Getting back to the Urbana meeting, too much goes on at standards meetings for me to cover everything. Therefore, in this report I’ll pick out the things that particularly caught my eye, and that I think will be of particular interest to readers. With this in mind, I’ll cover the developments in the concurrency TS with regard to Executors, I’ll catch up with the Concepts TS, and I’ll give a brief update on the networking TS. First, however, something in the Evolution Working Group (EWG) came to my attention, because we discussed it in the BSI C++ Panel meeting at the end of last October, and because it has come up more than once over the years in the discussions on ACCU General. I’m referring to a proposal to make it possible to overload operator dot.

Operator dot

The proposal to make operator dot overloadable, by Bjarne Stroustrup and Gabriel Dos Reis, is entitled simply, Operator Dot (N4173). The idea is to be able to write ‘smart reference’ classes, similarly to how we currently have smart pointers. The ARM [3] explains that not allowing this in the first place was a conscious decision, so it is ironic that one of the authors of the ARM (Bjarne Stroustrup) is one of the authors of this proposal. This paper has met with a mixed reception. At the BSI C++ Panel meeting, there was concern about the possible effects, for example the possibility that some templates coud be made unsafe (a statement I’m not going to attempt to justify here, but which I hope to come back to in the future). Also, there was concern about the potential for causing general confusion. However, there was also some agreement that the idea is well motivated i.e. smart references are potentially useful, and it would be easier to write proxy classes. There was a consensus (in the BSI Panel meeting, and when this proposal was discussed by the Evolution group in Urbana) that the authors should be encouraged to continue this work.

Concepts

I first covered the topic of Concepts Lite in my May 2013 report i.e. the one that followed the Bristol ISO meeting where Andrew Sutton (the author of the proposal) gave his presentation on the Wednesday evening. The proposal was well received and generated a lot of interest, but things have been quiet on this topic of late. That’s partly because recent work has been focused on C++14 (now an international standard), and partly because the Concepts work that has been carried out, has been in the background for a while. Note that there was never any ambition to get Concepts Lite ready in time for the C++14 standard. Instead, the goal was to produce a TS. I wondered if the committee might aim for C++17, but the goal is still a TS i.e. the original plan hasn’t changed.

As the Urbana meeting began, the Core Working Group (CWG) began work on reviewing the current Concepts Lite draft, with the hope that a PDTS (Preliminary Draft Technical Specification) might be voted out by the end of the meeting. Unfortunately this was not achieved. By the end of the Tuesday session the author had a number of edits to make and work went on until the end of the Thursday session. However, at the end of that session a straw poll revealed that there was no clear consensus for the paper being ready to move to the PDTS stage. In the absence of a positive consensus, clearly the PDTS [4] will have to wait for more work to be done.

Executors and the Concurrency TS

I have already commented (in previous reports) on the dropping of Executors from the concurrency TS. Also, last time, I reported on the discussion of the two ‘competing’ Executers proposals that took place at the SG1 two day meeting last September. The two proposals are Executors and schedulers, revision 3 (N3785) by Chris Mysen et al, and Executors and Asynchronous Operations (N4046) by Christopher Kohlhoff. Both these papers now have updates (following the SG1 meeting) in the pre Urbana mailing: the former is N4143, and the latter is N4242.

Here, there is some good news, at least in my opinion: Executors have still not been put back into the concurrency TS. Further, in Urbana, SG1 concluded that the concurrency TS should go to the PDTS stage without Executors. I think this is good news because of the lack of certainty over which Executors design C++ will eventually use. I should expand on that comment a little.

Previously the Executors design included in the concurrency TS (before the removal) was taken from Chris Mysen’s proposal. Following the SG1 face to face meeting it was looking like that was going to be the case once again (with Chris Mysen updating his proposal to take ideas from Christopher Kohlhoff’s into account). I have previously commented that Christopher Kohlhoff’s proposal has been well received, and is preferred by some members of the BSI C++ Panel (me included). Therefore, with the concurrency TS not committed to either proposal, there is still time for it to make more progress and possibly become the Executors design adopted by C++.

In passing, note that the current version of Working Draft, Technical Specification for C++ Extensions for Concurrency (N4107) hasn’t changed since the post Rapperswil mailing. However, the pre Urbana mailing contains a paper entitled Improvements to the Concurrency Technical Specification (N4123). I’m not going to comment on the latter, but I thought it would be worth drawing readers’ attention to it.

Networking

The BSI C++ Panel meeting of December 2014 brought to my attention another paper by Christopher Kohlhoff: Networking Library Proposal (Revision 3) (N4332), which appears in the post Urbana mailing (revision 2 is in the pre Urbana mailing). This paper is currently passing through the Library Evolution group. This proposal now joins the several other works in progress that are heading towards becoming TSs. The interesting thing about this paper is that there was already a networking TS in development but, in Urbana, Library Evolution took the decision to replace it with Christopher Kohlhoff’s proposal.

Finally

That’s nearly all for this report. Just one more thing before I finish: I need to mention the BSI C++ Panel meeting dates for 2015. These are: 9th February, 20th April, 8th June, 3rd August, 5th October and 16th November. All dates are Mondays. Anyone who wants to get involved can contact me in the first instance.

Acknowledgement

Thanks to Roger Orr for his email reports from the Urbana meeting, which he posted to the BSI C++ Panel reflector. They were very helpful to me in writing this report.

References

[1] Pre-Urbana mailing: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-10

[2] Post-Urbana mailing: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-11

[3] The Annotated C++ Reference Manual by Bjarne Stroustrup and Margaret A. Ellis.

[4] For information on the PDTS stage, and other stages that TSs go through during their development, see: https://isocpp.org/std/iso-iec-jtc1-procedures.

Notes: 

More fields may be available via dynamicdata ..