2D or not 2D: that is the question: Rapperswil trip report

Beautiful Rapperswil

The summer 2018 ISO C++ committee meeting took place in Rapperswil, apparently something of a favourite with the members. Being a short flight from my home I was able to arrive on Sunday afternoon, ready to start on Monday without fear of jet-lag. The last time I was in Switzerland was by accident when I went Interrailing in 1989. It was good to return and see what state my German is in.

I shared a flight to Zurich with several committee members as it turned out, including convenor Herb Sutter. Thinking I would be able to be very  helpful with my schoolboy German, I was surprised to discover Herb has very good German. He is a man full of surprises. We shared a taxi to Rapperswil (thanks Microsoft!) and I excitedly demonstrated the latest samples written with the 2D Graphics library on my iPhone.

My expectations for this meeting were centred around what seemed like a do-or-die defence of the 2D Graphics proposal, P0267, against the Diet Graphics proposal, P1062, during the evening session of day four, Thursday. I presented the paper to the C++FRUG in Paris a week earlier, and had decided that my course of action was to polish and reduce the content while reviewing proposals in LEWG and LWG. The absence of the lead author Michael McLaughlin was a considerable handicap for me but I was determined to represent the work to the best of my abilities.

Rapperswil is gorgeous. I checked in to Hotel Jakob, as did two of the co-authors of P1062, and took a long walk around the town. It’s located on a beautiful lake, surrounded by mountainous terrain; everything was clean and neat and tidy, even the light industrial units I strolled past. I decided this was going to be a delightful week.

Carrying on where I left off

The P1062 co-authors joined me for breakfast. Professionalism is of the utmost importance and actually there’s more to life than opinions, beliefs and papers. The opening plenary commenced at 09:00 at Hochschule für Technik Rapperswil (HSR), our hosts for this meeting. Peter Sommerlad is a professor of software engineering at HSR and leads the Institute For Software, and started by ensuring we were all wearing rather fetching scarlet baseball caps, decorated with the white cross of the Swiss flag surrounded by a C and a +.

C++ Swiss Flag style
C++ Swiss Flag style

This committee was large: there were over 150 experts in attendance, and the introductions took over ten minutes. After rules and administration were covered, I went straight to LWG to carry on where I left off.

To advance the 2D paper I need to be better at writing wording; in Jacksonville I wanted to spend plenty of time in LWG just learning what the wording concerns are, but fell ill. I still feel there is plenty to learn, and spent the next two sessions of the day in LWG soaking up the process. I could feel my imposter syndrome fading as I understood what was going on with the papers: it’s hard to put into words, but the same sort of concerns appear time and again, and I was starting to be able to see them before they reached discussion in the group. We adopted quite a few papers that day.

During the fourth session I worked on my presentation. The Paris version ran for about an hour, and it’s not reasonable to spend that long talking to people at an evening session. I reviewed what could be culled and what was important, before seeking out a pizza dinner with colleagues. The weather had been gorgeous all day while we were closeted in our meeting rooms, but suddenly turned stormy in the evening.

This time last year, at my first committee, there was a session on terse/natural/simple syntax for Concepts. This is an addition to Concepts syntax, and doesn’t hold up the rest of the TS. This continues to be an unresolved problem and there were two presentations, one by Herb and one by Bjarne, presenting two different options. The session stretched out beyond three hours, at the end of which no overall consensus was apparent. I forget the numbers (I was struggling to stay alert), but it was something like 20 to 22. I couldn’t help feeling it’s time to flip a coin, but that’s not how the committee works. On we go…


Rapperswil in the summer is gorgeous. It’s worth emphasising. The morning light was glorious and I took a moment to sit near the lake before heading back to LWG for some Standard Library Concepts work with Casey Carter, P0898. This involved reviewing a three-way merge between this paper, the C++ Working Draft and the Ranges TS, yielding four colours, cyan, red, gold and magenta to describe different additions and withdrawals from different sources. Take a look. It’s fabulous.

I spent the second session in LEWG as I was very interested in the discussion on constexpr <vector>, P1004. This is a big deal for compile-time programming, particularly strings and reflection, and we forwarded the paper to LWG. This should make C++20. Then my friend and colleague John McFarlane presented his fractional numeric type, a precision-preserving mechanism for carrying out non-integer arithmetic (John, I think it’s actually a rational numeric type myself).

Well, would YOU photograph an animal attacking you?
It’s a duck, not a swan

I was joined at lunchtime by Hana Dusíková who you may know from her astonishing compile-time regex presentation at CppCon 2017. We dangled our feet over the edge of the lakeside, enjoying the tranquil scene, until a swan swam by with her cygnets and bit my toe. Fun factoid: the only people in the UK allowed to eat swans are the Royal family and fellows of St John’s College, Cambridge, on June 25th. I decided against revelling in my non-UK opportunities.

I returned to my presentation after lunch, working on the notes to my remaining slides, and then went back to LWG to look at one of the oldest outstanding papers, P0019 on atomic_ref, which after a second review on Thursday morning was forwarded for adoption into C++20. There were further small things in the final LWG session of the day, and then it was time to party.

Peter Sommerlad had arranged a quite grand event at the castle up the hill from the committee venue. There were alpenhorns, beers, wines and food, in a convivial and stunning environment. I and the rest of the committee were delighted with our host’s choice and our sponsors’ generosity.

An unexpected turn of events

Everyone was a little delicate this morning. I really did drink rather too much at the party.

I dragged myself in at 08:30 ready to continue The Work with LEWG. Titus, the chair, asked for a scribe. Attendance was low. I don’t know what possessed me but I volunteered, in the hope of acquiring hero points. We went through P1026 and P0645.

The first of these is a call for a Data Persistence study group. iostreams is old and the subject of much moaning. This is of particular interest to me: I maintain the memory and IO work in the Total War codebase. Things have changed considerably in the past twenty years as RAM has plummeted in price and kernels have implemented page file backed virtual memory more efficiently. iostreams is no longer “good enough” and there is scope for standardising much more efficient persistence. Do read the paper and join in if this interests you.

The second paper is a long overdue replacement for printf. I first saw this at Jacksonville and am delighted to see the work nearly completed: we decided to prioritise this for the IS, and I hope to see it in C++20. I try to scribe at least once per committee, and scribing is an excellent way to properly acquire understanding of papers, regardless of your mental state at the time.

The next session was devoted to parallelism. I’m still trying to get my head around the detail of this TS, and this was one of those sessions where I was a rather passive observer, but I stayed to try and gain greater understanding.

After lunch I continued tweaking the presentation; storm clouds gathered over the lake in dramatic style. I returned to LWG for P0323, std::expected. We didn’t complete reviewing.

The evening session was billed as a presentation on The Role of Technical Specifications in the evolution of C++, but was a wider presentation of P0939, Direction for ISO C++. I wondered if there would be any air-time given to discussion of the graphics proposal since it is targeting a TS, and the direction paper, in a small aside, does call for the inclusion of a lightweight drawing library by C++20 if possible.

Against my expectations, nearly an hour of the discussion focused on the proposal, with extensive discussion of the motivation for such a thing. There was much debate about the educational value. Personally, I’m not so convinced about the educational motivation although it is certainly the case that new users are always going to be more motivated by visual feedback of their efforts rather than simple character output. Things got quite stormy, and I was relieved that this was happening during this session rather than during my session the next evening.

I was very grateful to the direction group, particularly presenter Michael Wong, for their efforts. However, I needed to comprehensively rewrite my presentation in the light of the discussion.


I attended one LEWG session today, featuring Herb’s proposal for zero-overhead deterministic exceptions, P0709, and Peter Dimov’s proposal for adding support for type-based metaprogramming to the standard library.

I’m rather excited about zero-overhead exceptions. I prefer this model of error propagation to the rather baroque method of custom propagation via error codes, along with the separation of exceptional code paths. There was strong support for reclassifying out-of-memory errors, along with classification policy for errors, contract violations and so on, as well as discussion about withdrawing std::logic_error whose presence is in itself a logic error, particularly with the introduction of contracts into the language that happened this week.

Walter Brown presented Peter Dimov’s paper. This proposes introducing a library based on Boost.Mp11 into the library. We keep reinventing this particular wheel, and it’s time we put a stop to that.

For the rest of the day I rewrote and rehearsed my presentation. If this were an 80s blockbuster film, now would be the time for the montage.

The evening session on graphics was chaired by Jeffrey Yasskin. He was the chair of LEWG during the development of the proposal. The purpose of the session was to find a way forward, with a new proposal, P1062, being presented followed by my presentation of the current proposal.

At the start of the session there was no overall consensus on whether or not we should proceed with ANY kind of graphics proposal, let alone one or the other, so there was a lot of ground to cover. P1062 offers a refutation of the need for graphics support, and finally proposes a simple asset importing API, while P0267 offers a richer drawing library. Bryce Adelstein Lelbach ran through the content of P1062, and then I presented running samples, showed some code snippets, described the history of the paper and its reception, highlighted the problems of design-by-committee that it had been exposed to and described some ways forward.

Sadly, much of the discussion was about the potential of the speculative proposal rather than the bird in the hand that is P0267. I didn’t make enough noise about simplicity and portability. “Yes” voters left early to return to their rooms in Zurich. Polls of members’ positions were taken regularly, and eventually there was sufficient consensus to stop pursuing 2D graphics in the standard. There was no celebration, just disappointment.

Several thousand hours of work has gone into this proposal, and we need a way of preventing this from happening again. Sentiment transformed from strong long-term support in Toronto to ambivalence in Jacksonville, and this episode sends a rather unpalatable message to those seeking to undertake large proposals. I am confident the committee will find a way of tightening up the proposal and review process to maintain focus and consistency, probably by making demands of proposal writers such as providing a motivation, an abstract, a revision list, a review history and a named champion who will see the proposal through to the end, in addition to providing the actual content.

I deployed the Second Davidson Device in my ruminations paper P0988: my first, least-desired suggestion on how to proceed was to “Nuke it from orbit, it’s the only way to be sure. Buy this author a beer and goto end”. I wasn’t expecting a scorched-earth outcome but the upside was that I bought no further beer during the week. We repaired to a local beer garden and I was loaded up with beer by Bryce and others until I decided I really did have to go home and break the bad news to the rest of the team.


Yeah, whatever.

I spent the day in LEWG licking my wounds. The Work goes on, although to be honest it’s a bit of a blur and I wasn’t really taking much in the way of notes. I was most nudged by a proposal to add stack tracing, monadic operations for std::optional, support for contract based programming, and the fixed capacity vector.

At lunchtime the BSI caucus met to review the week’s proceedings. Everyone expressed disappointment at the outcome of the graphics evening session: there had been unanimous support for the TS and an assumption that there would be availability for programmers soon.

The evening session was devoted to the tooling subgroup, and particularly package management. We have a long way to go yet but I remain excited if apprehensive.

Next morning, the closing plenary saw the adoption of many motions and some interesting wrinkles in the voting process. One vote attracted no consensus and went to the National Bodies (NB) instead, who again did not demonstrate consensus, so the motion was not adopted. The ISO is a federation of national bodies, and although the closing plenary votes are taken from those present who are listed in the global experts directory, NB opinion is the fallback position. I’m a bit of a governance geek, and I found this very interesting: National Bodies are important, representing the opinions and wishes of the community of C++ developers the committee seeks to serve, and we ignore them at our peril.

Committee adjourned, but even though it was over, groups remained to continue further work. There is still a backlog. I returned to LEWG to support P1007, Timur Doumler’s paper on std::assume_aligned which formalises what every compiler does with alignment hints. I caught the train to Zurich airport with Jon Wakely and we watched Switzerland glide past beautifully while we discussed the future of the graphics proposal and its contents.


Just because the committee doesn’t want to publish the 2D Graphics TS doesn’t mean the 2D Graphics TS won’t get published…

14 thoughts on “2D or not 2D: that is the question: Rapperswil trip report”

  1. Hmmm – assuming your library P0267 is as good as it sounds. Why not propose it for membership in Boost. Were it toe be accepted, it would rule the C++ world for quite a long time.

    1. Thanks Robert. There are already different plans afoot, and I’ll be posting here within the next month to outline them. Boost is another possibility too. Watch this space.

  2. To paraphrase Pink Floyd: “How I wish, how I wish I was there…”. But I wasn’t and, more importantly, I do not believe that the result would have changed if I was. As far as I’m concerned, I couldn’t have done better than you did. P1062 was rather unfortunate in many ways, but I went into 2D graphics over four and a half years ago knowing that it could potentially falter at any time. The only thing I didn’t know going in back then was exactly how complicated it would be to get it right. Better 4.5+ years with a good product than far less time with something that wouldn’t meet the C++ communities needs.

    I’m proud of and grateful for your efforts, especially in Jacksonville and Rapperswil, and your contributions to and support of our 2D Graphics TS proposal. I’m deeply grateful for the support we’ve received from the BSI, other NBs, and so very many people involved in C++ standardization. And, to quote a film, “Goonies never say die!”

    1. Thanks Mike. It’s been quite the ride, and it’s got me to four countries between committees and conferences. I’m sure it’s not over yet.

  3. Great write-up Guy. But clearly I cannot let your fractional comment pass without a response. You’re right that it’s a rational numeric type but so are integers, floats and fixed-point types. It is also a fraction (“A ratio of two numbers, the numerator and the denominator” to quote Wiktionary) whereas integers, floats and fixed-point types do not explicitly have both a numerator and denominator. Want me to ping you next time it’s up for bikeshedding in LEWG?

    1. That’s not a bad argument. Sadly I don’t think I’ll be back at committee until next summer for Cologne, but if you’re STILL going through the mill then, I would be delighted to have an argument.

        1. CppCon is actually looking possible now. It overlaps with my birthday, which is unfortunate, but when you get to my age it’s less important. Bring it on!

  4. Thanks for all your hard work, Guy. And sorry about the frustrations…

    On a side note, I didn’t realize you had a special interest in constexpr vector. There has been a flurry of activity in the past year to make that and various other things possible for C++20. Now that all the machinery is in principle in place (i.e., past EWG), it will be interesting to see what we can do with it. The primary motivation was our new tack on reflection (SG7), but I’ve heard a lot of positive feedback from the people working with embedded environments.

    1. Thanks Daveed. I’ve been resting for a couple of weeks now and I’m ready to carry on! Frustrations are part and parcel of this industry, so I’m no stranger to disappointment.

  5. How frustrating. Maybe it was for the best.

    A 2d API in the standard sounds like a very good idea at first. But I don’t think people realized how big graphics API’s are. Or how many foundational abstractions and libraries are missing from the standard, that a graphics library should ideally be built upon.

    I think the only way to get a graphics API into the standard is slowly and in pieces. First a linear algebra library. Maybe executors, event handling, unicode, color spaces, io-device query interfaces, data pipelines, resource streaming, etc. Then 3rd party graphics libraries could make use of all these standard libraries, and they would be half standardized already. Maybe one of them would have a chance to get all the way.

    1. You’re not the only person to suggest that. My next large paper is co-authored with Bob Steagall and aims to start introducing linear algebra to the standard. It is long overdue and, using the templated math solution we used in the graphics paper, should allow all manner of optimisations.

      However, don’t forget that the purpose of the library was to provide lightweight drawing functionality, not a total end-to-end solution for GPU thrashing: that would be way beyond the bounds of a single proposal.

  6. I have one problem with Graphic library for C++, could it be used for in professional games like Total War? This is impossible except if you copy OpenGL or DirectX completely. But what if we do this other way? Instate of reinventing wheel C++ will only common foundations (backend) for this other APIs? Goal would be to remove OS part and not crating new Graphic API. Image C++23 application that use DirectX version that is compatible with C++ standard will compile on Linux without any IFDEF.

    This new C++ common graphic base for graphic could have some small predefined functionality that could be used standalone but for most part it will be used for base for other bigger APIs. With something like that every AAA game company could benefic from this.

    1. By no means: the proposal was for a lightweight drawing API, not a fully powered graphics API. I do think the name became something of a lightning conductor for ill-informed opinion about motivation and usage.

      Also, it remains entirely feasible to implement the drawing library using DirectX or any other lower level graphics library. If you want better performance, reimplement the backend! That’s why there are customisation points.

Leave a Reply

Your email address will not be published. Required fields are marked *