Standardization process

[sgayda2]

Sorry if this is the wrong place or the wrong way to ask, but what is the status of Standardization for the P1935 paper and this library/package? From what I can see, there was a bit of effort made to go through the relevant committees but it seemed to have stalled and stopped.

Is there still an aspiration or a plan to continue with the proposal for C++26/29/beyond? How does this compare to other libraries for example AU (https://github.com/aurora-opensource/au)?

[mpusz]

Hi Stoyan, P1935 was never meant for standardization by itself. It was a so-called "discovery" paper. It was received warmly by the Committee, and it seems there is (was?) an interest in the standardization. Next, we worked on the implementation experience and waited for feedback from the production. I was not happy enough with the initial design to propose it for standardization which is why the following papers were never created, and I worked on the V2 design for the last year (and still do). I am really happy with the results. I think that the V2 is standardization-worthy, and I plan to provide three new papers at the next Autumn meeting at Kona. We will see if the Committee is still interested in having this as a part of the Standard Library in C++29.

AU author is an mp-units contributor. Most of the authors of other successful and still maintained libraries are also on board. We want to work together to ensure that we will land the best possible library in the C++ standard.

[RalphSteinhagen]

@mpusz, you also have our support! This is important, and looking forward to this standardisation effort. Let me know how I can help ...

[RalphSteinhagen]

@mpusz what keeps you from getting this into the standard for C++26? This is an established problem with many different solutions. Standardisation should (in theory) be a straightforward process, shouldn't it? You do not seem to need new language features but more of an agreement on how to name/express things efficiently.

Am I missing some pertinent information/view angle? 🙈

[mpusz]

C++26 will be closed in 5 ISO meetings from now. There is no chance we will make it on time.

This is an established problem with many different solutions. Standardisation should (in theory) be a straightforward process, shouldn't it?

Well, not necessary. I am not sure if you followed the V2 discussions but there is plenty of new things there and they should prove in production first.

[RalphSteinhagen]

I see and believe I understand. Having this in the standard would give this a lot more weight. Also, this ties in nicely with the other C++ security/safety aspects that need, IMO, to be tackled... sooner rather than later if C++ aims to remain relevant.

... should prove in production first.

We'd be happy to guinea pig this at FAIR since this is important for safe and reliable real-time control of our accelerator facility. Also, we are working with the good folks at GNU Radio and potentially using physical unit safety there would go a long way further.

As you indicated, the main thing would be to have a robust, stable, yet intuitive API that does not get in the way of getting things done. A large part of our ecosystem is still about early prototypes, where we'd like to make the transition from prototype to industrial/scientific application as smooth as possible. For our part, we cannot afford to develop things twice.

Many devs are still a bit reluctant because this -- while IMO super important -- is a big step away from what they are used to. Keep the onboarding and transition as simple as possible would help.

N.B. Many of our (& GR) developers are stuck post-C++11 in terms of C++ usage and experience.

[mpusz]

We'd be happy to guinea pig this at FAIR since this is important for safe and reliable real-time control of our accelerator facility. Also, we are working with the good folks at GNU Radio and potentially using physical unit safety there would go a long way further.

That is great to hear! 😃 Please let me know how I can help you to get started.

For our part, we cannot afford to develop things twice.

I totally understand that, and I am really sorry that V2 breaks everything for the users. Nevertheless, I believe that the V2 is so much better that it excuses the breakage and is the right way to go.

I am so happy with the V2 design that I do not believe there will be many breaking changes in the public interface. Although I am still waiting for feedback from the production projects and authors of other libraries (@chiphogg, @bernedom, @nholthaus) that agreed to share their experience and help with the standardization efforts. I am so excited about the fact that we can work together to find the best possible solution and try to make it an international standard.

Of course, there is still a lot of work left to do, but those should be small incremental changes or optimizations of the underlying implementations (i.e. to fix compilation on other compilers, improve compilation times, or the quality of generated error messages).

The two major things that are left to solve that may impact a user-facing design are:

• non-linear scales (How to support non-linear scale? #35)
• proper algebra of vector and tensor quantities (Consider adding expression templates support for norm, dot, and cross products on vector quantities #463)

This is why I would like to approach those ASAP.

[mpusz]

We are happy to announce that we have submitted three papers for the upcoming ISO meeting 🎉 :

• LEWG - https://wg21.link/p2980
• SG23 (Safety) - https://wg21.link/p2981
• SG6 (Numerics) - https://wg21.link/p2982

Please let us know if you have any feedback or questions.