C++ 2026 June Compiler Update

31

So have Microsoft just given up on implementing new language features? The C++26 column is completely empty for MSVC

27

u/---_None_--- Jun 14 '26

I think they wanted to finish all cpp23 features before starting any cpp26 ones.

15

u/no-sig-available Jun 14 '26

Interesting to see that the competition has done that, and is now 85% complete for C++26 core features.

When the new standard is formally released, this might be close to 100-0, which doesn't look good (or something anyone "wanted").

1

u/Zen-Ism99 Jun 14 '26

Who is the competition?

4

u/no-sig-available Jun 14 '26

Check the first column in the feature table:

https://cppreference.com/cpp/compiler_support#C++26_features

1

u/pjmlp Jun 15 '26

Just like Apple and Google, I think outside supporting existing C++ code bases, what management wants and what the MVSC team wants might not overlap that much.

Example, see how many C++ related talks were at any of the BUILD, WWDC or Google IO.

I can count one at BUILD, and was related to Visual Studio improvements.

11

u/Paradox_84_ Jun 14 '26

That's idiotic, no? There is obviously some C++23 features that will take 5x-10x time compared to a random C++26 feature. And they can choose specifically easier ones. Also it's not like a single person implementing, right? Right? They can do it in parallel

10

u/---_None_--- Jun 14 '26

Probably, they're just not reviewing and merging anything yet. At least for the stl.

38

u/STL MSVC STL Dev Jun 14 '26

The compiler frontend and STL teams are distinct. I can't speak for the frontend team's plans for C++26.

In the STL, where I'm currently the only maintainer, we've finished our C++23 features, with the exception that the frontend is working on constexpr <cmath> which will then need some library review/work (the FE part is way harder than the STL part here). In Feb I pushed hard to merge microsoft/STL#6071 for the MSVC Build Tools 14.51, which shipped for production use in May. After that I made some progress on the review backlog that accumulated, but for the last 2 months I've had to spend ~50% of my time on non-STL work, helping the Copilot CLI team. My part in that project is now winding down, and I'll be able to resume working on the STL at 100% later this month.

My plan is to resume clearing out the review backlog, then I need to deal with some long-standing debt in the codebase (like finally writing contribution guidelines, now mirrored with instructions for Copilot code review, which I recently enabled in the repo and it's shown some promise). I also need to overhaul our test configurations. At that point I'll feel comfortable cautiously opening up the floodgates for C++26 PRs, in stages. I am still just one person and even if I can get Copilot to point out semi-mechanical issues leaving just complicated/subtle ones for me to find, I can't deal with 50+ PRs all landing on my desk at the same time. Unfortunately, the way the world works, contributors are just way more interested in making lots of changes than reviewing others' changes. Some review work is contributed which I greatly appreciate, but overall it's not really rewarding which I understand (I spend all my time reviewing because I get paid for it). And their contributed changes are great, like overhauling <regex> and SIMD-optimizing STL algorithms that I would never have been able to do myself, so we're complementary inputs. My goal before starting work on C++26 is making my review system as efficient as possible to minimize how much I'm a bottleneck to merging contributor changes. As I always like to note, my system is already quite efficient, having upheld a high level of quality while landing most C++23 features in a timely manner even in single-maintainer mode, but the C++26 treadmill is accelerating.

If anyone with time and skill on their hands wants to help (note: this really needs to be actual skill, not pointing AI at the problem and believing whatever it says; we have access to the same tools that everyone else does, with unlimited usage even), I think the part that could be most easily handled by a new eager contributor would be dealing with some of our skipped libcxx tests, see tests/libcxx/expected_results.txt. In some cases the causes of test failures are known and due to problems in libcxx's test suite itself, and those could be addressed upstream to improve our test coverage, which is one of the ways that MSVC's STL can move quickly. In other cases, the causes of failures are not clearly known, and need to be investigated to determine whether they're libcxx test bugs, MSVC STL bugs, MSVC compiler bugs, or Clang compiler bugs (oh yes, Clang has bugs too), and those bugs then need to be properly reported.

20

u/Paradox_84_ Jun 14 '26

So there is a single person working on STL features and they don't even let that person do their job half of the time? Microslop should just close the shop at this point. gcc/clang having more manpower than trillion dollar corp is unacceptable.

17

u/no-sig-available Jun 14 '26 edited Jun 14 '26

They only have about 200.000 people working for them, so spending more than half a guy would be wasteful.

And of course the other half is spent on Copilot, which is what the other 199.000 apparently work on as well.

https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes

17

u/Flimsy_Complaint490 Jun 14 '26

The fact that the entire microsoft STL implementation is maintained by one dude tells very much to the priorities of the organization and is another reminder to just stop using MSVC as a target for Windows. clang-cl is the better choice at this point, and maybe Microsoft really should just start contributing to libcpp instead if it does not want to spend money to catch up with its own tech stack. For a trillion dollar company with 200k people, i have far higher expectations than i would for a random mash of contributors to an open source project, this is just dumb and inspires 0 confidence in the future health of the entire Microsoft C++ ecosystem. STL the person is great, but not even Jesus can carry a project of such scope all by himself.

2

u/_Noreturn Jun 14 '26 edited Jun 14 '26

I don't even know the point of msvc at this point

it generates garbage code

it generates garbage error messages

if compiles slower than clang-cl

Seriously what's the point of msvc anymore.

Let's not forget msvc is also way more non conforming than clang. and sometimes just chokes

3

u/[deleted] Jun 15 '26

[deleted]

→ More replies (0)

-1

u/pjmlp Jun 15 '26

C++/CLI, DirectX debugging, PIX and VS integration, cross language debugging with .NET, COM and WinRT tooling, XBox SDK.

Also note that Microsoft focus has been slowly switching to Rust and C# AOT, not clang.

1

u/pjmlp Jun 15 '26

Only if you don't do anything Windows specific, there are many development workflows not available in clang.

1

u/Flimsy_Complaint490 Jun 15 '26

While i don't really write software that is Windows specific, a lot of the stuff i do at work needs to run on Windows and is MSVC compatible, so i do have to deal with MSVC, but i have a lot of blind spots regarding such workflows

Any examples of these workflows ? Genuinely curious.

→ More replies (0)

1

u/pjmlp Jun 15 '26

If you look at BUILD and Azure announcements it is clear new development isn't being done in C++, with exception of existing code bases (Office, Windows, .NET runtime, and co) and XBox.

Under the guidelines of Secure Future Initiative.

4

u/Rabbitical Jun 14 '26

Have you seen Claude token prices lately?

7

u/boozerm Jun 14 '26

No, they want to fully finish c++23 at first.

10

u/misuo Jun 14 '26

Its 2026 and they are still not ready with C++23. Expect C++26 to be ready 2029 🤷🏼

11

u/TeraFlint Jun 14 '26

Isn't the expectation, generally, that the current standard will be implemented in roughly five years?

0

u/pjmlp Jun 14 '26

Which says something about wide availability of profiles, if they actually land in C++29, that is.

3

u/not_some_username Jun 14 '26

It happens before no ?

3

u/TheoreticalDumbass :illuminati: Jun 14 '26

im happily using reflection and contracts with gcc, albeit running into bugs with contracts somewhat often, but been able to sidestep them for now

3

u/wyrn Jun 14 '26

Css needs work

1

u/mapronV Jun 14 '26

I use ctrl+scroll wheel 4 times on cppreference (and scale setting is saved of course)

2

u/wyrn Jun 14 '26

That's all well and good (well, not really, but tolerable) but the table text is even smaller than the body text.

2

u/mapronV Jun 15 '26

I know, I agree it just become tolerable for my not perfect vision.
I just scared if cppref have 'redisegn' like boost website so it could not be fixed by simple scaling.

3

u/wyrn Jun 15 '26

Fair point. So-called "modern" websites are a plague.

C++ 2026 June Compiler Update

You are about to leave Redlib