Q3 2024 priorities

[StephanTLavavej]

In the third quarter of 2024, our priorities are:

• Implementing C++23 features and LWG issues from the Working Draft
  • We have multi-collaborator feature branches for P0429R9 <flat_map> #2910, P1222R4 <flat_set> #2912, and P2502R2 <generator>: Synchronous Coroutine Generator For Ranges #2936
• Keeping PR reviews flowing, so contributions are reviewed promptly

If you have questions about our plans for this quarter, feel free to ask them here. (Note that compiler, IDE, etc. priorities are off-topic.)

[jovibor]

Time to reveal all the secret plans for the Q3 2024.

[frederick-vs-ja]

I wonder whether this issue would be reused if nothing gets changed for Q3. 😿

[StephanTLavavej]

Good idea, I'm a lazy kitty. 🐈 💤

[vrubleg]

I would tell that it's even more convenient when the same ticket is reused, so you can subscribe for this ticket only if you want to follow what's new in priorities ;)

[jovibor]

Meanwhile, the cppreference page reveals some spoilers😶:

[fsb4000]

@jovibor
Yes, it's me. The number might be inaccurate. I will change it if needed in the future. I found the information here: https://github.com/microsoft/STL/wiki/Changelog#expected-in-vs-meow-preview-1

Hi @MahmoudGSaleh, could you ask your bosses to use the latest version of the STL for VS 17.12 Preview 3? I know that new changes are now for VS Next, but VS 17.12 is the last version for VS 2022 and the last version for Windows 7, so it would be great if we could add all available features to it. We have a precedent for this in the past; we did the same for some VS version before CppCon, if I remember correctly. I also found some similar commits:
https://github.com/microsoft/STL/wiki/Changelog/_compare/88d93b32258075d95eb29878ff2d685035a68c2a
https://github.com/microsoft/STL/wiki/Changelog/_compare/8c66ad0069df3a4f2d501dd96cfa377d45315fe7
https://github.com/microsoft/STL/wiki/Changelog/_compare/a88d51ced71b3f5d47d4ebd5e47ccbe1a459716e

And we would have a chance to merge P2502R2 : Synchronous Coroutine Generator For Ranges to VS 2022...

[CaseyCarter]

Hi @MahmoudGSaleh, could you ask your bosses to use the latest version of the STL for VS 17.12 Preview 3? I know that new changes are now for VS Next, but VS 17.12 is the last version for VS 2022 and the last version for Windows 7, so it would be great if we could add all available features to it. We have a precedent for this in the past; we did the same for some VS version before CppCon, if I remember correctly.

FWIW, there will be a VS 17.13. If we can get generator (at the finish line), flat_map, and flat_set finished in a couple of months, then we can ship a C++23-complete STL in 17.13 without any heroics. We can worry about potential heroics when and if necessary, but it's going to be a harder sell than the time we were pushing MSVC-wide to ship C++20 entirely complete for CppCon.

[fsb4000]

Great news @CaseyCarter! Thank you for the info. I was confused by VS Meow.

[frederick-vs-ja]

FWIW, there will be a VS 17.13. If we can get generator (at the finish line), flat_map, and flat_set finished in a couple of months, then we can ship a C++23-complete STL in 17.13 without any heroics.

LGTM!

I have a few questions on ABI which are related to the potential use of [[msvc::no_unique_address]].

• When will/should ABI freezing happen for C++23 library components in MSVC STL?
• Are the ABI compatibility and stability ever desired for ICC & CUDACC?

[jovibor]

So, to clear the air.
Will there be a VS Next (ABI breaking) after the 17.13, or is it still under some NDA?

[StephanTLavavej]

@fsb4000

I was confused by VS Meow.

We only learned for sure that there would be a VS 2022 17.13 very recently - and as soon as that happened, I updated the Changelog to remove the placeholder.

I deliberately said "Meow" and not "Next" in an attempt to convey "we don't know whether this will be 17.x or 18.0". Feel free to ask for clarification if you're confused about release plans - we try to share as much as possible.

@frederick-vs-ja

When will/should ABI freezing happen for C++23 library components in MSVC STL?

After we're feature-complete, but not immediately after (we're not making that mistake again). I believe I'd prefer N+2: if we reach feature-completeness in Update N, then adding /std:c++23 and declaring an ABI freeze should happen no earlier than Update N+2 given how long our release pipeline is. (Typically, as Update N is releasing, the window for getting changes into N+1 is almost closed.)

That said, if we want to mess with ABI, there's nothing stopping us from doing so now (especially now that we have Clang 18). Major changes should be front-loaded.

Are the ABI compatibility and stability ever desired for ICC & CUDACC?

As far as I know (and, having been here 17+ years, I would hope that I know), we don't officially support Intel's (new) compiler. We don't go out of our way to break it, and we'll fix unintentional egregious breakage when it's easy (including 80-bit long double, a special historical case), but we don't test with it. (And in a "we actually don't support such usage" way, not in a "we theoretically support this but we don't continuously monitor that it keeps working" way, like for old-but-barely-supported OS targeting, or ARM32.) As far as I'm concerned, this means that we don't take into consideration any of its bugs or feature limitations when working on the STL - taking that stuff into consideration is what support means, and it's a major cost.

We do support CUDA (and theoretically we should support all of its Standard modes, although we don't yet test basic "does this even compile all headers" beyond C++14; I believe it currently supports up to C++20). We haven't made an exception for CUDA in our ABI compatibility promises. I remain very unclear on how the CUDA build process works - the way in which they send most code to the host compiler (i.e. MSVC) after their front-end splits out code for the device compiler (GPU) means that I think something like no-unique-address wouldn't be "special" for CUDA. I could easily be wrong.

@jovibor

Will there be a VS Next (ABI breaking) after the 17.13, or is it still under some NDA?

To clarify:

• At some point, we expect that the VS 2022 17.x release series will end, and a new major IDE version VS SomethingOrOther 18.x will begin.
  • Speculating about final branding (i.e. what SomethingOrOther will be) is both confusing and pointless, so I strongly discourage everyone from doing so (and I am glad to see that it has not happened yet).
  • I now have a decent idea about how many 17.x updates there will be, and their associated timeframes, but this is the one thing I can't share (and it's not certain anyways).
  • As previously announced, we've used up all of _MSC_VER=193x and have reserved _MSC_VER=194x for VS 2022 17.x. There will be a plan for larger values of _MSC_VER, but we don't know specifics yet.
  • We've gotten ultraboss blessings to drop Win7 targeting in 18.0, and I am very eager to merge that as soon as possible. Doom has been foretold and I will be delivering doom with expedited shipping.
• We continue to have no news about a "vNext" ABI-breaking toolset. When we know something, I expect to share it immediately.
• It is unlikely that the "vNext" ABI-breaking toolset will be perfectly aligned with a new major IDE version.
• I consider it likely that we'll continue shipping v14-compatible libraries (frozen in terms of new features, but usable with the latest compiler).
• What I expect is that in the middle of a VS release series, the vNext toolset will appear in an experimental form - starting as a copy of v14 before it undergoes extensive overhauls. Once we've done enough overhauling, we'll capture it as an ABI-frozen version.
  • It was recently suggested that we continue to keep an "evergreen" ABI-unstable vNext, infrequently capturing it as ABI-stable versions, to avoid getting into this problem where we lose the institutional and ecosystem capacity to deal with ABI changes. This would simultaneously satisfy users who want the latest improvements (and have the ability to rebuild the world from source) and users who want stability and prebuilt artifacts. That sounds like an excellent idea to me and I strongly support it, but it is not yet confirmed.
• I don't know anything about what opt-in vs. opt-out defaults will look like.
• I do know that I'll strongly resist any suggestion of adding new features to v14 and vNext simultaneously (we tried that and it wasn't feasible) - a clean switchover for feature work is important.
  • Getting the VS 2015-compatible release series up to C++23 conformance is like retrofitting Apollo with a warp drive. Users will need to accept that we can't keep delivering new features in that series forever.

At this time, we don't have management approval to begin work on vNext. It hasn't been rejected or anything, but we've been so overloaded with other priorities that we've paused making the case for it. (This is unlike open-sourcing VCRuntime, which we've abandoned any attempt at.)

[jovibor]

What I expect is that in the middle of a VS release series, the vNext toolset will appear in an experimental form - starting as a copy of v14 before it undergoes extensive overhauls. Once we've done enough overhauling, we'll capture it as an ABI-frozen version.

• It was recently suggested that we continue to keep an "evergreen" ABI-unstable vNext, infrequently capturing it as ABI-stable versions, to avoid getting into this problem where we lose the institutional and ecosystem capacity to deal with ABI changes. This would simultaneously satisfy users who want the latest improvements (and have the ability to rebuild the world from source) and users who want stability and prebuilt artifacts. That sounds like an excellent idea to me and I strongly support it, but it is not yet confirmed.

It would mean that there would be two toolset version in support simultaneously, if I get it right?
Any PR would need to have two versions then, for stable and for "evergreen" toolset (branches)? Double work.
Please clarify if possible, this is interesting.

[vrubleg]

The answer is right after the quoted part:

I do know that I'll strongly resist any suggestion of adding new features to v14 and vNext simultaneously (we tried that and it wasn't feasible) - a clean switchover for feature work is important.

[jovibor]

The answer is right after the quoted part:

Still, it's unclear.
What about standard's DRs that must be backported? Any current code fixes?
It's still double work.

[StephanTLavavej]

I'll want essentially the same policy that we have for previous VS releases - only security fixes and critical bugfixes. VS 2017 15.9.x and VS 2019 16.11.x are still being serviced (they're up to 15.9.66 and 16.11.40) but we haven't touched them with STL changes in a very long time.

DRs and LWG issue resolutions are generally not critical to backport. A bug has to be really bad for us to consider servicing it to a previous 17.x release, much less a 16.11.x release etc.

The goal is to avoid double work as much as possible. It really all comes out of the same pool. Over the years we've learned how to work with maximum efficiency (avoiding ultimately wasted work like backporting, and avoiding shipping buggy code as much as possible), and I don't want to start compromising that. We can barely keep up with Standardization as it is.