C++23 official flag(not /std:c++latest)

[TheStormN]

On-Topic

Hello,

I see from https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance that C++23 on STL level is completed. However, there is still no official flag like /std:c++23 and using /std:c++latest is not a good option to propose in a commercial product. The question is when can we expect official C++23 support?

Off-Topic

I also see that in terms of compiler C++23 features, pretty much nothing is done, which is a bit sad given that C++23 is more of an incremental update compared to C++20. Perhaps the official /std:c++23 flag is not available because of that?

Other major compilers are pretty much done on C++23 in both library and compiler support(although still missing some key C++20 features) and they already do provide official flags for switching to that version.

Perhaps MSVC strategy is to declare official support only when both library and compiler do support everything? If that's the case, perhaps it would be better to follow what other major compilers are doing. They add the official flags with missing features but at least the features which are already available are considered stable so they can be used while waiting for further updates. I guess this is the idea of the features tests macros. To be able to declare stable support for what you have and not keep everything under the "testing compiler flag".

Also is there anything the community can do to help about the core language features? I'm not sure why the compiler itself is not getting much love this time...

[AlexGuteniev]

I see from https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance that C++23 on STL level is completed

Not really. That page apparently lists only completed feature. See https://github.com/orgs/microsoft/projects/1142

So it is far from complete. (And you can do it less far by contributing flat_set flat_map and generator branches)

[cpplearner]

They add the official flags with missing features but at least the features which are already available are considered stable [...].

That's not quite true. According to https://gcc.gnu.org/projects/cxx-status.html, GCC still considers -std=c++20 to be experimental. Only C++17 is stable.

[cpplearner]

See also https://developercommunity.visualstudio.com/t/std:clatest-is-a-bad-idea/1286321

[TheStormN]

@AlexGuteniev Strange, given that they list uncompleted compiler features but don't list uncompleted library features... Anyway I've recently opened my first PR about a bug fix and I have a few more smaller things cooked up, However, they depend on some of the already existing PRs to be merged in order to be able to publish them, When we reach that state I might try to work on something way more challenging like the flat_* stuff but it's a bit unmotivating to do much work on STL(or any other project) when reviews and merges can take several months. @StephanTLavavej gave a really nice explanation on the current situation(which I totally understand and respect) and that basically he is the only one currently working on STL from Microsoft which is really sad. We had such a nice pace with C++20, strongly outperforming all other compilers and I hoped we would keep it up, especially for more minor standards like C++23 but it seems the big bosses have other plans. :(

@cpplearner I think GCC statement Important: Because the ISO C++20 standard is very recent, GCC's support is experimental. is kind of outdated. Perhaps they didn't updated the text as C++20 now is not that recent? :)

Your second link seems to directly answer my question. C++23 flag will be created only when all the stuff is considered feature complete which is a bit sad, given the example of other compilers, but I guess this is the bosses decision.

[StephanTLavavej]

For the record, we're planning to add a /std:c++23 flag only after both the STL and the compiler are feature-complete (i.e. all features have been implemented with only bug-level issues remaining), and some amount of time / number of updates have passed such that we can confidently lock down the ABI for C++23 STL features. The last time, for C++20, we rushed the ABI lockdown and addition of /std:c++20, which was a mistake (<format> was undergoing a high rate of churn), and had to delay it at the last moment. We won't be making that mistake again. At this point we can't say how long we'll let the ABI bake - it's possible that the STL will have time to bake while the compiler is finishing up their features. I'd personally like at least two updates (e.g. STL feature complete in X.Y, ideally an even-numbered long-term-support Y, then lock down ABI in X.Y+2 at the earliest).

The ABI guarantee is what's really important about /std:c++23. Technically, /std:c++latest emits a warning about being "experimental", but in practice we don't treat such features differently when it comes to support and bug fixing. (If anything, the priority is usually regressions first, bugs in new features second, and then long-standing bugs in existing features last. Fixing bugs in new features helps avoid accumulating debt, and is usually less disruptive because far less code is affected.) The special thing about /std:c++latest is that we allow ourselves to freely change class representations, which allows us to fix correctness and performance mistakes.

As for when the STL will be C++23 complete - as Alex mentioned, it is largely dependent on contributors, with maintainer capacity being a secondary bottleneck. (We try to move very fast in our feature/flat_map, feature/flat_set, and feature/generator branches, giving PRs targeting them only a lightweight review and check that the tests are passing. If you look at our PR backlog, feature/* PRs rarely accumulate.) We are blocked on a number of compiler-dependent features, although as soon as Clang supports them (and we can upgrade our dependency), the STL can add "light up" support and declare completeness, as we've already done in the past for a few features. constexpr for <cmath> will need the most integration work.

As for the MSVC compiler front-end C1XX being C++23 complete, we can't share an ETA at this time. They haven't started working on this yet, but they're aware that they need to soon.

it's a bit unmotivating to do much work on STL(or any other project) when reviews and merges can take several months.

Sorry! I totally understand how the review backlog has that effect. You've actually caught us at a particularly bad time - it was better a few months ago. We actually had a much worse backlog accumulate (80 PRs at the max) around the beginning of 2022, and 40 at the beginning of 2024, which we managed to dig out of and get down to just 1 stalled PR as recently as April 2024 - see the Status Chart's PR line. Then, for the reasons I explained, I fell behind a bit and thus the current backlog. If you look at our Code Reviews project (this is my main priority), I'm getting ready to merge over half of the backlog and make progress on the rest, including your PR.

Now I need to actually do that work instead of talking about the work. :joy_cat: Hope this helps explain things somewhat. Thanks for helping us and I hope to improve your experience as a contributor soon.

[AlexGuteniev]

Technically, /std:c++latest emits a warning about being "experimental", but in practice we don't treat such features differently when it comes to support and bug fixing

But when I wear my "responsible technical lead" glasses, the warnings as it is spelled out totally prohibits adoption in the production. Maybe if it said ABI-unstable rather than experimental, it would allow us to go with /std:c++latest rather than /std:c++20 in our ongoing VS2022 migration.

[StephanTLavavej]

There's always the risk that WG21 could substantially modify or entirely cut features that have been voted in (we had to do that once with a library feature!), and while we try to ship features at production quality (especially in the STL), they inherently haven't had a lot of usage experience when they initially appear. Ultimately it's a judgement call on both sides. "Experimental" seems to be a reasonable characterization to me.

[cpplearner]

What about adding /experimental:c++23 (following the precedent of /experimental:module and /experimental:preprocessor)?

[TheStormN]

I was about to ask the same. Currently c++latest will include C++26 related stuff too, which can cause troubles later when the real C++23 flag appears and CMake starts to use it and accidentally someone used C++26 stuff in the codebase. :)

Btw @StephanTLavavej is there any chance to convince bosses and compiler teams to open source the front end? Community work can really speed up their progress too and you already have quite nice example with STL.

[StephanTLavavej]

What about adding /experimental:c++23 (following the precedent of /experimental:module and /experimental:preprocessor)?

As a technical matter, that would be trivial to implement (so easy, I could probably do it in the compiler driver, and I am a novice when it comes to compiler changes). It's a design question - would it be worth the complexity of having to explain yet another flag, this one differing from the "linear" sequence of /std:c++14, /std:c++17, /std:c++20, /std:c++latest? On the other hand, as @TheStormN mentions, it would allow us to draw a distinction between in-progress C++23 and in-progress C++26, which we are currently unable to do.

Currently c++latest will include C++26 related stuff too

That is not actually a problem for us, as we have refrained from implementing any C++26 features conditionally, whether in the compiler or STL. (We've implemented several papers voted in during the C++26 cycle as retroactive, de-facto Defect Reports, which is a different matter.)

Even if we did have switches that allowed us to distinguish C++23 from C++26, I think we would still not start working on C++26 until C++23 is done, at least in the library, since focus is important. This might be a problem in the future (a problem I would like to have :joy_cat:).

is there any chance to convince bosses and compiler teams to open source the front end?

It's not forbidden by any conservation law, but realistically speaking I don't see any chance of this happening in the current environment, without significant changes happening in the company. At this point we don't believe we could get approval to open-source VCRuntime, which is a far smaller request.

(I would personally like C1XX to be open source, but it would absolutely require more FE dev capacity to review and merge PRs while avoiding disruptions. The FE is a more complicated environment than the STL, with everything depending on everything else.)

Back to reviewing put_time... :smile_cat:

[frederick-vs-ja]

Currently c++latest will include C++26 related stuff too

For core language features, I believe this is only true for Clang-cl (17.0~19.0), and it's a bit unfortunately that C++23 mode can't be specified for Clang-cl with /std:c++NN. I don't think MSVC has started any work on C++26 features at this moment.

Other "C++26 related stuffs" are only de facto DRs, which are also backported to C++20/23 modes by other implementations (as mentioned by @StephanTLavavej), and freestanding feature-test macros.

Note that freestanding FTMs are also required for hosted implementations despite being, IMO, meaningless. I guess if we can start to support freestanding modes, the freestanding additions in C++23/26 (and so on) will be backported to old modes. But I have no idea whether freestanding modes will be supported at all, although I'm very interested.

[TheStormN]

(I would personally like C1XX to be open source, but it would absolutely require more FE dev capacity to review and merge PRs while avoiding disruptions. The FE is a more complicated environment than the STL, with everything depending on everything else.)

I would disagree a bit here regarding the PR review capacity. I mean, if the community is doing like 30-50% percentage of the work I believe doing PR reviews would be far better than actually writing the code. Also in some of the companies I've been, there was a rule for every team member to dedicate 1 hour every day for code review. In some teams we even did co-reviews - like gathering the team into the meeting room and reviewing PRs together for 1 hour. I tend to use that rule for myself and people on which I can have influence even if the company in which I'm does not mandate it.

However, this is just personal opinion and observation. What works and what does not always depends on many other factors and I'm really grateful for your detailed explanations.

[TheStormN]

@frederick-vs-ja What do you mean by freestanding modes?

[frederick-vs-ja]

@frederick-vs-ja What do you mean by freestanding modes?

See this page.

[cpplearner]

@cpplearner I think GCC statement Important: Because the ISO C++20 standard is very recent, GCC's support is experimental. is kind of outdated. Perhaps they didn't updated the text as C++20 now is not that recent? :)

For the reference, https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659605.html indicates that GCC's maintainer still considers C++20 to be experimental.

[StephanTLavavej]

Closing as I believe the question has been answered here - please let us know if you have any further questions! :smile_cat: