Using `C++2a` as a `cppdialect` triggers the Default dialect (C++14)
What seems to be the problem?
I wanted to use C++20 Draft version as C++ dialect in my project (the latest C++ available), and I specified C++2a as the cppdialect for the project, following this documentation that states it's the value to use for that.
However, once I generated the project in Visual Studio 2019, I found that the language is the default Default (ISO C++14 Standard). This might be the default version triggered, so I initially thought it was something I was doing wrong, but just changing the cppdialect to C++latest actually works and enables the C++20 Draft.
I also checked the GitHub documentation for this to see if there was something wrong, and apparently it looks like it's still under construction.
I made a screenshot to illustrate the problem:

The current configuration I have in the premake is the next one:
workspace "WksName"
... [some specifications here]...
project "ProjectName"
kind "ConsoleApp"
language "C++"
cppdialect "C++2a"
staticruntime "on"
... [more specifications here]...
The ...[more specifications here]... is just stuff that I'm configuring and removing here for clarity (they work properly always). Using the latest label will work fine for me now, but I think this might still be worth flagging.
What did you expect to happen?
C++2a triggers usage of C++20 Draft.
What have you tried so far?
Using C++2a triggers Deafult (C++14), using C++latest triggers C++20 Draft (actually shown as Preview - Features from the Latest C++ Working Draft (/std:c++latest).
How can we reproduce this?
By specifying C++2a as a cppdialect and generating the project (for me it's Visual Studio 2019, not sure about other IDEs or versions), then checking the C++ version used.
- [x] Visual Studio 2019 (vs2019)
What version of Premake are you using? 5.0.0-beta2
Probably documentation should be updated... Visual doesn't handle all gnu++XX and "non finished" version (C++0x, C++1y, C++1z, C++2a) (and ignore them, so default is used). C++20 would be better to use anyway.
@premake-team: modules/vstudio/vs2010_vcxproj.lua#L1634
elseif (cfg.cppdialect == "C++20") then
table.insert(opts, "/std:c++latest")
should be fixed though:
According to https://learn.microsoft.com/en-gb/cpp/build/reference/std-specify-language-standard-version
/std:c++20 might be used for recent version of visual.
A warning for unsupported cppdialect would be fine too IMO.
Where are you seeing that elseif at @Jarod42? Current language standard related code in VS exporter doesn't look like that.
Hi @Jarod42 & @nickclark2016 ! Thanks for the quick answers.
Yeah, I wanted to use C++20 initially, but then I had to switch to the latest C++20 Draft to use one part of the standard library that's only there. As I say, using C++latest works for that, so it's fine, but I just wanted to flag this in case there was something to do about it.
I think the initial thought on the cppdialect flag was that we'd only support the language versions explicitly called out by the toolchain and C++latest, so we didn't support the GNU and C++ draft versions in VS. As it currently stands, I don't see this as a bug, but a documentation deficiency.
@nickclark2016: It is there modules/vstudio/vs2010_vcxproj.lua#L1634.
Ideally, I think exporters should warn about unsupported fields. (pretty sure we will disagree on that ;-) )
At minima, documentation should be updated.
Nah, I agree that they should warn. We just don't have the framework in place currently to do that.
@nickclark2016: It is there modules/vstudio/vs2010_vcxproj.lua#L1634.
Ideally, I think exporters should warn about unsupported fields. (pretty sure we will disagree on that ;-) )
At minima, documentation should be updated.
Ahh, I see what you're referring to now. Yeah, that doesn't really affect VS project files for 2019 and 2022, so the behavior appears correct to me. We use m.languageStandard to set the language standard in VS 2017 and newer.
Indeed, I miss m.languageStandard, so just doc to update, and warning later when supported. (A simple print would seem enough for me).
To confirm, doc to update == website, correct?
yes. that page
Hi again, thanks for taking care of this so quick, and sorry for my late responses, I don't check GitHub as often as I'd like 😅
So if I understood correctly, there would be no support for draft versions in Premake? Not sure if I understood it properly as I get a bit lost in the messages since I'm new to all this :)
Visual Studio does not support draft versions. If you want C++20, just use that. If you want the latest, use C++Latest.
Okay, so when you're selecting Features from the Latest C++ Working Draft (std:c++latest) in the VS properties it doesn't use a draft version? Or I guess it's just using only the latest draft but doesn't lets you chose a draft version?
Just asking as I'm not an expert in this, I tried checking VS Documentation but still I don't know how to relate it to your answer.
Correct, VS ignores draft revisions. If you want the latest draft, you use C++Latest, not C++2a. However, Visual Studio 2022 supports C++20 completely, so I'd recommend using C++20 instead of C++Latest, as the latest draft implementation includes things that are coming in C++23 (C++2b).
Oh okay, thanks for that information!
I was actually using C++20, but I wanted to use <format> and <chrono> libraries that I think are available only with the latest draft C++Latest and not with the standard C++20 version, so that's why I switched to the latest draft
Those are headers in C++20.
No, you can't include them with the standard version of C++20 (it actually says it in the VS docs), and not being able to include them was why I changed. The chrono one it is, but not its formatting side I think, which is under C++Latest.
There are still some MACROs to know if feature is officially supported (and __has_include too)...