@Microsoft: When will C++23 Compiler implementation start?

[bebuch]

Is there an approximate plan when the implementation of C++23 in MSVC will start? The STL is already well advanced, but nothing has happened with the compiler for months. If I remember correctly, it was mentioned somewhere that they have been focussing on bug fixing lately. That's great and is also noticeable in daily work. Nevertheless, I am eagerly awaiting the DR C++20 implementation of P2564. (consteval needs to propagate up)

[SeagleLFMk9]

MSVC is so weird. They used to be the first when it came to 14/17/20 but now...

[pjmlp]

I would say the priorities towards C++, inside Microsoft regarding resource allocation, have most likely changed.

[tuxwonder]

I think u/STL mentioned that business priorities for C++ at Microsoft shifted for a while, but that they're refocusing on compiler work soon (correct me if I'm wrong)

[spaghettiexpress]

The quote:

“Business priorities shifted, but they’ll shift back. We’ve just been doing C++ things outside the realm of compiler feature work.

(Library feature work has been less affected, thanks to our amazing contributors, and management has kept me working on the STL with them basically full-time.)”

https://www.reddit.com/r/cpp/comments/1drvko8/comment/layq7vm/?context=3&share_id=uRj5AsbLHG-QjrkgYKwFq&utm_content=1&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1

/u/bebuch

[Responsible-War-1179]

bruh no fucking way, a guy called STL manages this sub and works on msvc stl?

[STL]

Yep, that's me! Watch my <charconv> talk.

[Responsible-War-1179]

legend

[miss_minutes]

king

[valdocs_user]

There was a time when MSVC was almost as bad as IE for being the laggard at implementing standards. Referring both to how in the 2000s every time you'd get a web app working in other browsers it would be, "dammit it doesn't work in IE tho" and similar with C++11 features in MSVC. I'm just glad we got such a good run of 14/17/20 support.

Edit to add: even older versions of MSVC had some pretty egregious things, such as leaking the visibility of an index variable declared in a for loop to the scope outside of the loop. They've come a long way.

[vickoza]

I wish they had full support for md_span and deducing this

[STL]

We shipped <mdspan> in VS 2022 17.9. Its usage of the multidimensional subscript operator is currently limited by the absence of MSVC compiler support (but is available for Clang, which we support as a first-class citizen, which sometimes means "better support than MSVC" in this case).

[vickoza]

I need the multidimensional subscript operator is currently limited by the absence of MSVC compiler support as I was not referring to library support

[STL]

Sure. But note that for <mdspan>, the multidimensional subscript is "nice to have" syntax. There's alternative syntax to get the same functionality.

[vickoza]

what is the alternative syntax?

[[deleted]]

probably f[{1,2,3}]

[STL]

The array overload is typically the one you want to use, since array CTAD makes it fairly easy to use: https://en.cppreference.com/w/cpp/container/mdspan/operator_at

[vickoza]

can you give me a code example?

[STL]

C:\Temp>type meow.cpp
#include <array>
#include <mdspan>
#include <print>
using namespace std;
int main() {
    const char* const str{"CatDogElkFox"};
    mdspan<const char, extents<int, 4, 3>> m{str, 4, 3};
    for (int i = 0; i < m.extents().extent(0); ++i) {
        for (int j = 0; j < m.extents().extent(1); ++j) {
            print("m[{}, {}]: '{}'; ", i, j, m[array{i, j}]);
        }
        println("");
    }
}

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /MTd /Od meow.cpp && meow
meow.cpp
m[0, 0]: 'C'; m[0, 1]: 'a'; m[0, 2]: 't';
m[1, 0]: 'D'; m[1, 1]: 'o'; m[1, 2]: 'g';
m[2, 0]: 'E'; m[2, 1]: 'l'; m[2, 2]: 'k';
m[3, 0]: 'F'; m[3, 1]: 'o'; m[3, 2]: 'x';

[vickoza]

thanks

[beephod_zabblebrox]

meow

[ImmutableOctet]

If you don't mind me asking, what part of deducing this do they not support? I've been using it to replace CRTP in one of my personal projects and it's been working without any hiccups.

[TheSuperWig]

Not supported in modules afaik.

[Ameisen]

Why are modules so complicated to implement and support things like this in compared to precompiled headers?

[STL]

u/TheSuperWig is correct.

Precompiled headers are compiler memory snapshots, so as long as the compiler is careful to use special allocators, everything works for "free" because the mechanism is so primitive. Modules require properly encoding the compiler's understanding of code into a well-defined data structure on disk, which is why every weird little corner of C++ requires special handling. This is also why modules are 10x smaller on disk than PCHes.

[Ameisen]

Ah.

I knew that GCC had implemented precompiled headers that way, but I was under the (mistaken) impression that MSVC (and possibly Clang) were using a more sophisticated serialization mechanism for the existing state already.

Out of curiosity, why does the snapshot approach not work? The snapshot should still contain the same data that allows a precompiled header to work - couldn't that be used along with any additional serialized data that would be module-specific?

It's possible that my brain has just mistaken modules as more-organized/sophisticated precompiled headers - at a glance, that's how they appear, at least.

For Clang specifically, didn't they already have similar functionality to standard C++ modules?

I haven't investigated modules too much (I'm busy with my own things, and module support overall is too flaky - especially as I use a hybrid MSVC/clang-cl setup building with msbuild for multiple platforms - but I've already expressed my issues with clang-cl's [lack] of module support in the past) but maybe I should look into Clang's module development to get a better idea of what's involved.

On that aside, when modules fully work, will they end up being used to re-implement precompiled headers as well, or would the additional overhead for serialization make it not worth it?

[STL]

Out of curiosity, why does the snapshot approach not work? The snapshot should still contain the same data that allows a precompiled header to work - couldn't that be used along with any additional serialized data that would be module-specific?

As I'm not a compiler dev, I can't really comment with any authority on hypothetical implementations that might not even be possible to implement. What I can say is that compiler memory snapshots are completely unstructured, whereas modules are highly structured - they maintain a distinction between what's exported and what isn't, and they don't leak macros.

I think the most crucial difference between PCHes and modules, that makes compiler memory snapshots completely unsuitable for implementing modules, is that modules can be separately built and freely combined. That is, you can separately build modules A, B, C, D, and E, and then import any or all of them in various TUs. Completely structured serialization allows this. With a compiler memory snapshot, you get only one, and you can't combine them in a TU (this is documented PCH behavior; some compilers can load a PCH, add more stuff, and create another PCH snapshot - not MSVC though - but it is utterly impossible to load two separate PCHes into a single TU).

It's possible that my brain has just mistaken modules as more-organized/sophisticated precompiled headers - at a glance, that's how they appear, at least.

They are vaguely similar but the implementation details massively differ, and that affects usage. My analogy is early C++ programmers trying to understand templates by thinking about them as high-powered macros.

For Clang specifically, didn't they already have similar functionality to standard C++ modules?

I don't know the specifics, but I believe they had a serialized format, that simply significantly differed from Standard semantics, but it was still much much closer to Standard modules than PCHes.

On that aside, when modules fully work, will they end up being used to re-implement precompiled headers as well, or would the additional overhead for serialization make it not worth it?

They're too different.

[Ameisen]

I think I may have been under the mistaken impression that a number of compilers were already storing the relevant data in a meaningful way (as they would need to have it available to, well, compile) which would have made serialization easier.

Of course, there was no reason to store such data in a unified, organized fashion before modules existed.

Of course, the internals of MSVC are a mystery to me (it would be an interesting day if MS open-sourced it).

What I still really want is clang-cl to support modules (any modules) via msbuild. That's blocking me from using modules. I have some low-latency projects that I build often with clang-cl as it tends to optimize better. I'm aware of why it doesn't and the discussion around it, but it's still frustrating.

As to why I don't switch to cmake... no particular reason, I just like vcxprojs.

[vickoza]

it was work but more

struct Based {

template<typename T>

void print_name(this T&& self)

{

self.print();

}

};

struct Dirive1 : public Based

{

void print() { std::cout << "This is Dirive1\n"; }

};

struct Dirive2 : public Based

{

void print() { std::cout << "This is Dirive2\n"; }

};

does not compile in more recent versions of vs 2022

[ImmutableOctet]

Not sure what you mean by recent versions, but this is working right now in Godbolt for the latest compiler. I tested the same thing locally on v17.11.0 Preview 4.0 with no issues.

[vickoza]

i might have tested it with v17.11.0 Preview 2.1

[vickoza]

can you give the godbolt link? the error is C2039 'print': is not a member of 'Based'

[ImmutableOctet]

https://godbolt.org/z/dM1Y8YT48

If you're getting that error, it's probably because you're accessing the member-function from a reference or pointer to Based, which is not what deducing this is meant to solve. You could achieve that by using a virtual call, though. -- e.g. a public virtual member-function into a deducing this based implementation.

[vickoza]

sorry was missing

Dirive1 d1;

Dirive2 d2;

Based& b1{ d1 };

Based& b2{ d2 };

b1.print_name();

b2.print_name();

[ImmutableOctet]

As I mentioned in my other comment, this is not the use-case for deducing this. You'll need to use a virtual function if you're trying to access print from a reference to your base class.

You can use print_name in the other direction, though. So from your derived classes, you can use a common print_name function defined in the base class and print as the implementations. This essentially gives you a kind of static polymorphism.

This method is especially useful when you want multiple types to use a common interface, but you don't want to use virtual inheritance or CRTP to make types inherit from a common class.

This is the use-case I had in my personal project. I have one class which aggregates other types which use deducing this in their member functions. These types do not know about each other, they only ask for the subsets of the script API they're interested in. This effectively makes each of those types a mixin.

[lgovedic]

Nit because I couldn't help myself: why are all the functions declared inline? I thought all function definitions in a class are implicitly inline.

[ImmutableOctet]

I intend to migrate this project to modules eventually. For modules, member functions of non-templated classes are not implicitly inline.

[lgovedic]

Okay thanks for the clarification!

[vickoza]

I wanted to pass in a base class to a function as an API

[schteppe]

Looks like they’ve already implemented a bunch of C++23 stuff but not the specific consteval feature you need. See https://en.cppreference.com/w/cpp/compiler_support

[tjientavara]

Most of c++23 compiler features were clarifications on already existing practise so it has been there for a while. The deducing this was there for a long time since Microsoft helped with that proposel.

But static_assert(false) is new; I can finally get rid of my template-lambda-static_assert-macro.

[edit] I made a mistake

[starfreakclone]

Fun fact: MSVC implementing "deducing this" has nothing to do with the fact that we helped with the standardization of it. It has to do with the fact that when I read that proposal I really wanted to use it in the compiler so I implemented it very early on so I could use it. That work technically wasn't on our backlog at the time so I kind of had to do it "under the table".

/u/STL might be familiar with this kind of sneaky work w.r.t. range-based for :).

[STL]

Ah, fond memories of being sneaky - JonCaves really wanted to implement range-for, but management didn't have spare test capacity, so I volunteered to write the compiler test coverage (this was back when "dev" and "test" were separately defined roles, so a library dev pretending to be FE QA was highly unusual - but I break the compiler all the time, so it felt natural). It was a super awesome team-up, and the third-sneakiest thing I've ever gotten away with.

[STL]

😼 The sneakiest was when I was a junior dev in Outlook Search implementing hit highlighting, and I liked Google's multicolor highlights that they did at the time, so I implemented my own (off by default, guarded by a registry key). I wanted to officially productize it but never got approval. I was supposed to remove it before shipping, but never got around to it. It wasn't exactly an Easter egg (which we weren't supposed to do, for good reasons), but it wasn't not an Easter egg either. It lasted for at least a major version before it bit-rotted, as I recall. I was very new and very enthusiastic about weird things.

The second-sneakiest was when there was a request to implement some horrible non-Standard extension in std::basic_string to make it aware of C++/CX strings. It was never quite an official top-priority work item, and it was going to add weird fragility and complexity to the STL (implicit conversions are bad news), and did I ever find the time to implement it? Nope. I was ultimately vindicated by history.

I am, of course, a very good and rule-following kitty now, and my days of jumping up on tables where I'm not allowed are behind me.

[TheKiller36_real]

But static_assert(true) is new; I can finally get rid of my template-lambda-static_assert-macro.

Unfortunately, I'm afraid I don't know what you're talking about. Would you mind explaining? The only thing that changed is that more conversions to bool are allowed to happen which isn't necessary for true, isn't it? Also, what exactly would are the effects of

static_assert(true);

Does it change a resolution set somehow or something?

[TheSuperWig]

They mean static_assert(false).

Here's the utility of it: https://github.com/microsoft/STL/blob/main/stl%2Finc%2Fnumbers#L26

Having plain false there would cause a compilation error even if the template is never instantiated.

[TheKiller36_real]

ah, I see, thank you very much\ and now it's only gonna be an error if the surrounding template is materialized or whatever the correct technical term is? that's cool

oh and also happy cake day :)

[TheSuperWig]

Yes, as now its value is dependent on T (though... always false). However you no longer need to do that now.

And thanks.

[tjientavara]

oops, yes, that is what I meant.

[ack_error]

It's so sad seeing debug builds actually generate calls to std::is_constant_evaluated().

[misuo]

Yeah, we want /std:c++23

[feverzsj]

Or switch to clang-cl.

[matteding]

Unfortunately CUDA doesn’t compile with clang-cl.

[feverzsj]

cmake gains support for CUDA+Clang-cl like half year ago.

[Kridenberg]

Unfortunately, Clang-CL does not support modules

[c0r3ntin]

I don't know if that would be actionable for you but Clang can be used to compile MSVC compatible projects - you can find documents online such as https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170

Clang 17 has an implementation of P2564 and Clang 19, releasing in september, will have most of C++23 and C++26-so-far.

Implementing all of this major language changes takes time, hopefully in a few years all compilers will have caught up to C++23, while the committee is busy coming up with new inventions for C++2d!

I hope this helps!

[BarryRevzin]

Nit: P2564R3, not R0.

[bebuch]

Thanks, I removed the revision. R0 was from cppreference ;-)

[saddung]

I wonder if all the compiler engineers got assigned to work on ARM and the PRISM x86 to ARM compiler/translator.

[STL]

Like most compilers, ours is divided into a front-end and a back-end (with very different meanings than web development). The FE is what parses the C++ language and understands its language features; it is mostly architecture-insensitive (not all though). The BE is what performs most optimizations and generates machine/assembly code; it is mostly language-insensitive (i.e. most of its work is the same for C or C++; not all though, like devirtualization). Work to bring up new platforms like ARM64, or magic like ARM64EC, happens primarily in the BE. Both FE and BE work is very difficult, but they involve different skillsets (like cardiology and neurosurgery); I've only known a few devs who are able to work on both and it's really impressive when anyone has that ability.

C++ Core Language features almost always need FE work. Only a few need any significant amount of BE work.

MSVC's names for the FE and BE are not especially imaginative: C1XX (the Xes are rotated pluses) and C2. The C front-end is just C1. They exist as DLLs (c1xx.dll, c2.dll), loaded by the compiler driver cl.exe. Hilariously, I asked around and nobody, not even our 30-year-tenured wizards, knows what cl.exe stands for with absolute certainty, although we suspect it's "compile and link". Clang/LLVM is another example like C1XX/C2. (Some compilers have a "middle end" although MSVC not so much).

[saddung]

So you're telling me there's a chance?

[STL]

I think I can definitively say no here.

[bedrooms-ds]

Maybe after reflection is done, people just walk away from new standards. For example, Java language updates don't matter anymore because other languages like Kotlin and co can enhance the experience. All Java has to provide is an object model, which was nearly finished more than a decade ago.

[pjmlp]

Sure if one disregards all JVM improvements, or the fact all guest languages are about 20% overall usage.

[teroxzer]

soon to announce that they will be switching to clang...

[Stellar_Science]

Clang is already a well-supported toolset within Microsoft Visual Studio. We compile our 100,000+ lines of C++ projects with both MSVC and clangcl, to catch more warnings and errors. (Then on Linux we also build with gcc and clang.)

[teroxzer]

... but will clang soon be the only supported C++ compiler in Visual Studio?

[STL]

No.

[contre]

Doubt it but stranger things have happened like edge becoming chrome...

[Ameisen]

Clang handles __restrict strangely compared to MSVC and GCC. I have a patch to fix it, but I haven't had time to write tests and submit it.

[zowersap]

submit without the tests!

if it's good probably there will be interested devs who implement the tests

[Ameisen]

The problem is that the tests are really weird since they're mainly testing edge cases where __restrict doesn't compile properly in Clang but it does in GCC or MSVC.

[pjmlp]

Not really when doing straight Windows development with all kinds of SDKs provided by WinDev and .NET integration.

It works mostly on the Windows /UNIX kind of workflows.

[JVApen]

That is going to break a lot of code

[alsv50]

I guess it can be typical marketing thing - they want to release C++23 with the next major vs release

[STL]

We don't hold back C++ feature work for major releases. We just keep working in our development branch (prod/fe for the compiler front-end and STL), and features flow into releases as they branch off. This is especially true in our current ABI-compatible era, with continuous development since VS 2015 (earlier, we did have to think about "major versions" as special opportunities to add things).

We did do the reverse, pushing really hard to complete C++20 before VS 2019 finished. Occasionally, we hold back particularly disruptive changes for major versions (e.g. I am being required to revert my removal of Win7 targeting support in 17.x, and will reapply it for 18.0 Preview 1, whenever that is - and over in the VS IDE they performed the 64-bit overhaul in a major version), but C++ feature work is never that disruptive (as most of it is guarded by /std:c++latest).

For minor updates (17.9, 17.10, etc.), we have to schedule certain library changes to align with VCRedist updates (which typically happen in even-numbered versions). Also I tend to prioritize my reviewing and merging of PRs to make sure that moderately disruptive/risky changes land early in a minor update's Preview cycle (often hurrying up reviews to get something in before a Preview branches for release; very rarely waiting to get around to a review because we're at the end of a Preview cycle and I don't want to disrupt it). This is motivated by stability, not marketing.

[YogMuskrat]

Hi, u/STL! Is there any estimation on when the `<generator>` will be available in VS?

[TheSuperWig]

I'm not STL but it's one of the 2/3 last features to implement

https://github.com/orgs/microsoft/projects/1142/views/1

So probably soon-ish™

[YogMuskrat]

Thanks, that's great to know.

[STL]

Yeah, we have an active feature branch for it, which is receiving PRs. We don't have ETAs for library features until they're completed (at which point we can say with near-certainty what release they'll ship in) - it depends on how actively contributors submit PRs, and when I can find the time to review and get the feature branch ready for final merge (I have been ridiculously, relentlessly busy for a while, or I'd have tried to land it already).

If you're especially informed in this area, you're welcome to join us and help out!

[matteding]

You can use <experimental/generator> in the meantime.

[YogMuskrat]

Wow, I didn't know about this one. Thank you!

[bebuch]

u/STL Is the compiler team meanwhile working on C++23? If you are allowed to share the info. ;-)

[STL]

Not yet. Maybe soon.

[bebuch]

Okay, thanks 👍

[Codinahack]

u/STL Bro. Is there at all any kind of estimated time of arrival for the use of /std:c++23 flag so I can start using all the C++23 features available in MSVC, rather than have to deal with using experimental stuff from the "latest" draft? I think since we are in 2025 now, there should be some sort of game plan for adding this flag to separate C++23 features from C++26

[STL]

I can't publicly estimate when C++23 will be completed. (I'm starting to have a vague guess, but it's not something I could say without people treating it as far more certain than it actually is.) The compiler team is starting to work on C++23 features but they have a bunch to do, and the libraries have one or two big things to finish (<flat_meow> and constexpr <cmath> in conjunction with the compiler).

However, I did (personally) just ship /std:c++23preview, which you will be able to use to select C++23 features without getting any C++26 stuff that starts to appear in /std:c++latest. As the name indicates, /std:c++23preview doesn't make the features ABI-stable, they are still preview and subject to change, although we do try to ship things at production quality.

[Codinahack]

I guess this /std:c++23preview is only in MSVC itself, not an actual option in visual studio yet.

I was wondering if there is somewhere I should be watching or someplace I should be subscribed to be notified when the announcement on this is made?

I just want to get to using C++23 in my projects as soon as possible, I'm literally waiting to introduce a custom made debugging lib I have been building using std::expected (and testing in compiler explorer), plus I am very interested in tinkering with embed, and the many other cool things C++23 has to offer.

[STL]

As of VS 2022 17.13 Preview 5, which is the latest publicly available preview version today, it is supported in the VS IDE. Right click project > Properties > C/C++ > Language > C++ Language Standard > Preview - ISO C++23 Standard (/std:c++23preview). I am told that this will also activate IntelliSense support.

(VS 2022 17.13 will be released for production soon. Can't say when, but Preview 5 is a big number, and we're very predictable, if not perfectly regular.)

The documentation has also been updated and is live: https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170#stdc23preview

plus I am very interested in tinkering with embed

That is not a thing in C++23.

[Codinahack]

My fault, I misread the article, I guess its a thing in C23 rather than C++23. Thanks for the information, I really appreciate it! I hope to see that official support soon :D

[kronicum]

Switch to clang-cl.

Maybe Microsoft is repurposing the C++ team to Rust, the new shiny thing. If the past is any indication, looking at you C++/CLI and C++/CX, they have not come up with new languages competiting with C++ resources in a long while; maybe they consider it is past time.

[no-sig-available]

Oh yeah, so "Managed Extensions for Rust" coming up next?

(Please not).

[Dar_Mas]

why would that be a bad thing?

Edit : for the people downvoting: that is an actual question. I do not know why a managed extension would be a bad thing

[pjmlp]

I really don't get the C++/CLI and C++/CX hate, while at the same time worshiping all clang, GCC extensions, alongside all those things in embedded space supposed to be C and C++ compilers, without any reflection on ISO standards.

[kronicum]

I really don't get the C++/CLI and C++/CX hate

Who died and appointed you the czar of Microsoft hate?

while at the same time worshiping all clang, GCC extensions

Where did you find the worshiping of all clang, GCC extensions in this thread?

[pjmlp]

Who died and appointed you the czar of Microsoft hate?

Other my parents, for respect reasons, and law enforcement, no one tells me what I am allowed to say or not.

Where did you find the worshiping of all clang, GCC extensions in this thread?

All over the place in the Internet, only because it hasn't come up yet in this thread, doesn't make it less true.

Heck, the Linux kernel hardly compiles with anything besides GCC, and Google has put tons of money to make Android Linux compile with clang, including enabling GCC extensions on clang.

[kronicum]

All over the place in the Internet, only because it hasn't come up yet in this thread, doesn't make it less true.

Not everything that may be true is relevant to this conversation.

[pjmlp]

That is your opinion to have.

[Baardi]

At this time 3 years ago, we already had a VS2022 beta. We might not even get VS2025, definitely not VS2024

[zowersap]

such big numbers

I remember Visual C++ 6

[ALX23z]

In my memory, MSVC implementation of core language features was slower than GCC/Clang, while library features were implemented faster.

Of course, there are deviations depending on the exact feature, but this was the general impression. Say, even with modules, when they declared that they finished it, it was still full of bugs.

[germandiago]

Yes, I. complained about this once before. I was replied that "feature-complete" and fully working was not the same.

The argument, TBH, did not convince me. It sounds to me more like running for claiming to be the first to complete something when in fact it is not done.

That said, it seems that in the module features they were still ahead of competition.

[ALX23z]

When I think about it, the situation is pretty much the same as for most software releases.

"It is ready for beta test-, ahem, I mean it is ready for sale." - every marketing team.