Title: Standards Report

Author: Martin Moene

Date: 01 March 2015 21:18:33 +00:00 or Sun, 01 March 2015 21:18:33 +00:00

Summary: Mark Radford reports on the latest C++ Standardisation proceedings.

Body: 

Hello and welcome to my latest standards report.

In this report I’m rather short of events to report on. There have been no more full ISO C++ meetings, and the next one will be after I have to ship this report (sorry, I don’t have any information at the moment on what’s happening in the C standards process). There will be a BSI C++ Panel meeting on Monday 9th February, but this time I can’t attend and I’m not likely to see the minutes in time to write anything about it before I have to ship this report. There has, however, been an ISO C++ meeting dedicated to discussing the Concepts TS; this took place in Skillman, HJ, USA on the 26th, 27th and 28th of January this year. I wasn’t there, but one of my BSI C++ Panel colleagues was [1], so I have information on the proceedings.

Also a couple of C++ topics – namely, uniform call syntax and the overloading of operator dot (which I discussed briefly in my last report) – have come up recently. If either/both of these are achieved it would have an impact on the way C++ code is designed. Therefore both topics are important and merit some detailed coverage.

Skillman

The purpose of the meeting was to continue to review the Concepts document, and to determine the document’s readiness for PDTS publication. The meeting also agreed on the categorisation of issues found. While there were more than two categories, the fundamental point was whether or not an issue needed fixing before the PDTS could ship. Happily, during the process it was found that none of the issues were serious enough to prevent shipping!

Unfortunately, extreme weather conditions on the first day of the meeting dictated that it needed to be adjourned at lunch time. For the same reason it was decided not to meet face-to-face the following day, but to have a teleconference instead. Andrew Sutton, the Concepts document author, was asked to address the issues that had been found in time for the following day, so the changes could be reviewed by the meeting.

When the meeting reconvened, it began by going through the updated version of the paper. There were some additional comments, including issues raised (while the meeting was taking place) on the BSI C++ Panel reflector. However none of the new issues were serious enough to delay shipping. Therefore, the outcome was to move the document (with some editorial fixes) to PDTS.

Of course, the big question now is whether or not Concepts can make it onto C++17. The problem is that not everyone is convinced we have the right design. No one has a problem with the current Concepts design going into a TS, but that’s a very different thing from the International Standard (IS). While a TS can be a stepping stone to a feature going into the IS, the TS is also a proving ground i.e. something compiler writers can implement so real world experience can be obtained before a feature is committed to the IS.

Talking of real world experience, note that there is a Concepts branch of GCC; there was hope that the Concepts branch could be merged into GCC 5, but unfortunately this is now not going to happen as progress on the branch was not quite rapid enough. I don’t have the details to hand, but anyone interested in playing with this implementation should have little difficulty in finding the branch, which is publicly available.

Uniform Call Syntax

I see this topic is once again under discussion, having been discussed on and off for over a decade (many of the discussions being informal). A discussion on the Evolution Working Group (EWG) reflector drew my attention to it, that discussion having been sparked by two papers in the pre-Urbana mailing: ‘Unified Call Syntax’ (N4165) is by Herb Sutter [2], and ‘Call syntax: x.f(y) vs. f(x,y)’ (N4174) is by Bjarne Stroustrup [3].

There are several good motives for doing this. One example is greater flexibility for generic programming: given a template parameter T, when invoking an operation involving T the generic code has to commit itself to assuming one syntax or the other i.e. member function or free-standing function.

Historically, when this topic has been discussed, there has been an implicit assumption that the free-standing call syntax would potentially call a member function. A simple example is: f(x) could potentially call x.f(). However, in ‘Unified Call Syntax’, Herb Sutter looks at the problem the other way, suggesting that x.f() could also potentially call f(x). Note that, in particular, he says if the call can be resolved by a member function, then no further lookup should take place. This avoids any impact on existing code. Meanwhile, in ‘Call syntax: x.f(y) vs. f(x,y)’, Bjarne Stroustrup does not take any one viewpoint. Instead he presents a discussion of all the approaches to unifying the call syntax; this does not just involve syntax, as there are also various approaches to how the semantics would work: for example, if the f(x) syntax is preferred, should member functions be looked up only if no non-member match is found, or should they be included as equals for overload purposes? Note that the latter option is a silent breaking change, so I hope its inclusion extends to simply stating the complete set of options for comparison. I get nervous when I see such a silent breaking change even mentioned!

Anyway, I’ve said enough about those two papers in this report. Both are publicly available, so anyone who wants to know more can download them. I’ll move onto ‘Call Syntax Questions’ by Bjarne Stroustrup, a paper which he circulated on the EWG reflector and which is not currently publicly available. Currently, I don’t know whether or not it will be included in a future mailing. Actually, I suspect it won’t be: looking at the introductory remarks, there is an indication that feedback on this paper will be used to revise the original (N4174) paper. As I write this I see the new (Feb 2015) mailing has just been published [4], but I can’t see any new papers on this topic, or any updated editions of the two exiting papers.

‘Call Syntax Questions’ makes some compelling arguments against the x.f() syntax. For example: it feels “too object-oriented” may sound like an objection based on taste, but it starts to look like requiring x.f() is in rather bad taste when you consider that x.sqrt() looks rather strange, and 2.sqrt() just looks plain wrong! This is C++ of course, and what looks right/wrong in C++ isn’t necessarily the same as in other languages. Further, moving towards member function syntax encourages making functions members, thus increasing coupling. Finally, what about lambda functions passed as template arguments? They must be called using the f(x) notation. To quote the paper: “Not all opposition to x.f(y) is emotional and aesthetic”.

Operator Dot

In my last report I talked briefly about “Operator Dot” by Bjarne Stroustrup and Gabriel Dos Reis (N4173). This is the latest in a series of proposals to make “operator dot” overloadable (the paper mentions several of its predecessors). Clearly, the overloading of operator dot has its applications: smart references (by analogy with smart pointers) are an obvious one, and the facility to write proxy classes more easily is another. This proposal has been very well received and there is general agreement that the work should continue. However there are some concerns.

One of the concerns is the possibility of introducing silent changes to templates. For example, consider the following fragment:

  struct X
  {
    X& operator=(int i);
	int i;
  };
  
  struct T
  {
    X theX;
	T& operator=(int i);
  };
  
  T t;
  t = 42;

What you have to remember here is that t = 42 actually says t.operator = (42), which means that if T is modified as follows (i.e. with the added operator dot):

  struct T
  {
    X theX;
	T& operator=(int i);
	X& operator.() { return theX; }
  }; 

the actual meaning is t.operator.().operator = (42), which in turn means the assignment is really to x and not to t. If T were used as a template argument this would bring about a silent, and probably surprising, change to the code’s semantics [5].

Looking at this now, I’m wondering how much of a problem it really is. I’m thinking that overloading operator dot is really a design feature of a class, because it’s a smart reference or some kind of handle i.e. it’s not really the sort of thing likely to be added later on. Also, C++ is full of features that potentially cause pitfalls, and programmers should always think about the possible consequences of changing code. I know the fact that pitfalls are already in the language isn’t a reason to add more. However, overloading operator dot does have benefits, and the standards committee must always weigh up the benefits afforded by a new feature versus the problems it (potentially) causes. Anyway, the jury is still out on operator dot, but I think it’s one to watch with interest.

Acknowledgements/References

[1] Thanks to Dinka Ranns for the excellent reports (posted to the BSI C++ Panel reflector) from Skillman, on which I have drawn in my report.

[2] ‘Unified Call Syntax’ (N4165) is by Herb Sutter can be found at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4165.pdf

[3] ‘Call syntax: x.f(y) vs. f(x,y)’ (N4174) by Bjarne Stroustrup can be found at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf

[4] The latest mailing can be found at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/#mailing2015-02

[5] Thanks to Roger Orr for helping me understand this.

Notes: 

More fields may be available via dynamicdata ..