The story so far
The ISO C++ committee (WG21) did not reach consensus to pursue a 2D Graphics Technical Specification (TS) during the Rapperswil session. At the end of the week the British Standards Institute (BSI) C++ panel met for its pre-plenary caucus. This is where the panel decides what position to adopt so that the delegation lead can vote in the plenary meeting on proposals that aren’t unanimously supported, as happened with the coroutines proposal.
During the caucus, disappointment was expressed about the end of the graphics effort: the BSI C++ panel was very keen for adoption of some form of drawing library into the International Standard (IS). A long serving member pointed out that we could in fact publish our own TS, and we decided to discuss this at our next meeting, which took place on July 9th.
The ISO is a federation of national bodies, of which the BSI is one. Over a dozen national bodies participate in the C++ standardisation effort. Any body can publish a TS. Indeed, the BSI has published many TSes in other standardisation efforts, but never in the C++ subject.
A C++ TS is not part of the C++ IS. Particularly, from British Standard zero:
BS 0:2016, section 3.45
A TS is a document published by ISO, IEC, CEN or CENELEC about which there is the possibility of future approval as a standard, but for which at present there are reasons precluding immediate publication as a standard.
NOTE Typically the reasons for this would be that the required support for such approval cannot be obtained; there is doubt on whether consensus has been achieved or the subject matter is still under technical development.
This TS would be developed, reviewed and published independently of WG21. There is expertise within the BSI C++ panel competent to complete this work: there are experienced wording reviewers and implementers.
The BSI C++ panel post-Rapperswil meeting
Among other matters, we discussed the idea of publishing and unanimously resolved to propose a new work item for the publication of a 2D Graphics TS based on P0267.
This is new territory for the panel, and possibly for WG21. We still have to work out the process and cannot yet publish a timetable. However, what we will deliver will be wording sufficient for implementers, if they so choose, to implement the 2D Graphics library specified by the TS.
There is already a reference implementation and sample code for Windows, Linux, OS X and iOS. Emscripten support is in development. You can take a look, download and build it by visiting io2d.org. We expect to add it to the vcpkg package manager very soon which will simplify access. You can also take a look at the current version of the TS: be warned, it is nearly 200 pages long.
Why do this if WG21 is not interested?
The work to date is very valuable. It contains the result of extensive feedback from the WG21 committee and can act as a beacon to others.
Consensus is a fluid thing, as is the makeup of the committee: there was very strong consensus for several years to pursue 2D graphics and it would be foolish to believe the current consensus will remain forever. Even if another approach is pursued, the TS will offer a starting point.
There is still demand for a standard drawing library. Many of the national bodies were as dismayed as the BSI C++ panel by the new consensus. By publishing a TS this library remains a visible candidate.
Why not try standardising another library?
The proposal is the result of many thousands of hours of work from a small number of wording experts and graphics experts. Starting again from scratch on something else would delay the introduction of 2D graphics by years. However, if you would like to undertake such a thing, I’m happy to answer questions.
It is often overlooked that having a great idea is only the very start of the standardisation process. Developing the API is a small part of the job when compared against generating the unambiguous wording for the IS document.
Won’t this fork the language?
This is not a language feature. The library is currently defined in the std::experimental namespace and will be migrated to the bsi namespace.
Won’t package management solve this?
Sadly, no. Adding the implementation to vcpkg gets this library into the hands of all those who are permitted to use third party code. However, this is by no means a universal privilege. Many commercial, industrial, governmental, financial, medical and military code shops simply outlaw third-party code, even Boost, allowing only what is provided by the compiler vendor.
The phrase “dark matter developer” refers to those developers who simply don’t engage with the rest of the community: they are invisible, observed only by the effect they have on compiler sales. Often, these are developers who are denied access to the work of the community. In my opinion it would be worth trying to find out how big this non-community membership is. Last year’s C++ survey was self-selecting from community participants: maybe it is time to commission some professional research. We ignore these developers at our peril. If we do not serve them they may migrate to other languages.
Should WG21 decide to standardise package management in such a way as to overcome this barrier, perhaps with a “blessed” repository, then the TS will be in a strong position to seed such a library.
How can I help?
We welcome any and all assistance. You can:
- Write some samples or tutorials
- Propose text or input APIs
- Develop a new implementation
Samples and tutorials are the easiest way to help. That’s how everyone learns to use a new feature.
We are thinking about text and input a lot of the time. It’s hard. One of the team is a long-term contributor to SDL and has some ideas, but it’s good to have more to choose from.
The current implementations are software reference implementations, using Cairo or CoreGraphics. Perhaps you could write a DirectX, Vulkan, OpenGL, Metal or nv_path_rendering implementation. They don’t need to be perfectly optimised: they only need to demonstrate feasibility. If you run into trouble, you might be highlighting a fault in the design.
You can also contact your national body and your favourite compiler vendor and ask them to support the effort. Remember, you’re the customer. Look for details of these organisations on the ISO C++ web site.
This is a post about governance more than about C++. If there are any errors or if anything is unclear, please add a comment below and I will correct or clarify as soon as possible.
I recorded a podcast with the good folk of CppCast about this and other topics. You can find it here. Many thanks to Rob and Jason for the opportunity.