# Standardized C++ version expression as a language proposal

**URL:** <https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415>\
**Category:** Beman Libraries\
**Created:** [May 6, 2025, 4:38pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415 "2025-05-06T16:38:59Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 6, 2025, 4:38pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/1 "2025-05-06T16:38:59Z")

</div>

Suggested by @bretbrownjr

> A new beman library and paper for a C++ language feature for “cxx\_minimum\_required(17)”, syntax negotiable

Name pending.

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 6, 2025, 4:40pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/2 "2025-05-06T16:40:39Z")

</div>

First step is to figure out the name, does `beman.version_expression` work?

---

<div class="post-metadata">

**Author:** ![purpleKarrot](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/purplekarrot/32/127_2.png) [@purpleKarrot](https://discourse.bemanproject.org/u/purpleKarrot)\
**Post date:** [May 6, 2025, 5:09pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/3 "2025-05-06T17:09:25Z")

</div>

What about “C++ Policies”? I hope this command accepts an optional second argument `<max>` and sets the “policy version” to:

- the range’s `<max>` version, if specified, or to
- the `<min>` version, or to
- the value of the `-std=c++<version>` value if it is higher than the other two versions.

Sounds [famliliar](https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html).

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 6, 2025, 5:20pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/4 "2025-05-06T17:20:43Z")

</div>

Interesting idea, what should the beman library name be called?

`beman.policy`?

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [May 6, 2025, 7:55pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/5 "2025-05-06T19:55:23Z")

</div>

I was expecting to limit this to a static analysis check. I would like to leave semantic changed to C++ to another paper. That would be more like an epochs or editions feature, and that’s a whole other thing.

I don’t have a lot of specific naming ideas yet.

I suppose a maximum range is possible. I don’t know what the use case would be other than wanting to continue using deprecated features, and most compilers forward port those to future C++ versions with feature flags like the C++03 ABI setting in GCC.

It would make more sense to consider feature specific checks. Like asserting on the support of reflection or contract assertions.

---

<div class="post-metadata">

**Author:** ![Jeff-Garland](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/jeff-garland/32/23_2.png) [@Jeff-Garland](https://discourse.bemanproject.org/u/Jeff-Garland)\
**Post date:** [May 8, 2025, 12:25pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/6 "2025-05-08T12:25:53Z")

</div>

> [@bretbrownjr](#):
>
> It would make more sense to consider feature specific checks. Like asserting on the support of reflection or contract assertions.

Which we already have.

```auto
#if (__cpp_constexpr > 202211L )

   // Permitting static constexpr variables in constexpr functions 
   // https://wg21.link/P2647R1
   // and everything before it
#endif

```

Please explain how my code would change if any of this were _in the language_.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [May 9, 2025, 4:17pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/7 "2025-05-09T16:17:34Z")

</div>

I like the name `beman.policy`. It seems descriptive enough.

I think there are two reasons why this is an interesting feature:

1. Code which is designed to error out when a compiler+flags invocation lacks support for a particular C++ version is replicated all over the place. Such a feature would reduce this replication.
2. The compiler writer is much better suited to provide a useful error message than the folks writing this code. They can, for example, say “You’re using -std=c++11, but this file requires C++17, modify your compiler flags to say -std=c++17 instead” or even “Visual C++ 14.0 compiler lacks support for C++17 so will not be able to build this library. A newer revision of this compiler may have support. Go to [http://microsoft.com/vc++/language\_support](http://microsoft.com/vc++/language_support) for details”.

@purpleKarrot can you describe a concrete use case for the “second argument” feature you’re suggesting given C++'s backwards compatibility promises?

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 9, 2025, 4:35pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/8 "2025-05-09T16:35:28Z")

</div>

> [@dsankel](#):
>
> I like the name `beman.policy`. It seems descriptive enough.

I fear `policy` implies too big of a scope which is in conflict of what’s being proposed currently.

_Naming is hard._

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [May 9, 2025, 4:42pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/9 "2025-05-09T16:42:55Z")

</div>

What’s the conflict?

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 9, 2025, 4:44pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/10 "2025-05-09T16:44:39Z")

</div>

So sounds like @bretbrownjr wants a simple minimal version detection library. I fear `policy` gets folks aroused with putting too much stuff in.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [May 9, 2025, 5:46pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/11 "2025-05-09T17:46:23Z")

</div>

What about beman.minimum\_required?

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [May 9, 2025, 7:51pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/12 "2025-05-09T19:51:52Z")

</div>

I like David’s explanation. To add, I would like to be able to write a static analysis tool that suggests adding this sort of statement if it is missing.

I don’t expect analyzing procedural preprocessor directives would be a feasible way to write that sort of codebase modernization feature.

As to names, I am flexible, and I agree with River that something narrow is nicer when possible. I am OK with `beman.minimum_required`. `beman.cxx_required` or something similar could work too. I expect some amount of “bikeshedding” in the ISO discussions if this feature gains consensus to proceed to wording and beyond.

---

<div class="post-metadata">

**Author:** ![river](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/river/32/119_2.png) [@river](https://discourse.bemanproject.org/u/river)\
**Post date:** [May 10, 2025, 7:08pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/13 "2025-05-10T19:08:09Z")

</div>

Let’s take `beman.cxx_required`, I will go ahead and create a new repo if no one objects to this.

Edit: I will wait till this wed.

Edit2: I have been distracted with other stuff, if anyone’s intereseted, please go ahead and create said repo.

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [January 15, 2026, 10:22am UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/14 "2026-01-15T10:22:47Z")

</div>

**IMHO** : It can only be managed individually through implantation i.e.:

```cpp
// clang-format off
#include <version>

#if defined(__cpp_concepts) &&__cpp_concepts >= 201907L
  // C++20 concepts supported
#elif __cplusplus < 202002L
  #error "C++20 or later is required"
#endif

// detect standard header first, then experimental, otherwise use local implementation
#if defined(__has_include)
# if __has_include(<scope>)
# include <scope>
# define BEMAN_SCOPE_USE_STD
# elif __has_include(<experimental/scope>)
# include <experimental/scope>
# define BEMAN_SCOPE_USE_STD_EXPERIMENTAL
# else
// no std scope header — fall through to local implementation below
# endif
#elif defined(__cpp_lib_scope) &&__cpp_lib_scope >= 2023xxxxL
# include <scope>
# define BEMAN_SCOPE_USE_STD
#else
# warning "Missing feature __cpp_lib_scope"
#endif
// clang-format on

```

see [Add simple BEMAN\_SCOPE\_USE\_FALLBACK code · ClausKlein/scope@6f75603 · GitHub](https://github.com/ClausKlein/scope/commit/6f7560373938ac2dbe303c48a1cce99287e75dd9)

---

<div class="post-metadata">

**Author:** ![Jeff-Garland](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/jeff-garland/32/23_2.png) [@Jeff-Garland](https://discourse.bemanproject.org/u/Jeff-Garland)\
**Post date:** [January 19, 2026, 4:08pm UTC](https://discourse.bemanproject.org/t/standardized-c-version-expression-as-a-language-proposal/415/15 "2026-01-19T16:08:49Z")

</div>

> [@ClausKlein](#):
>
> can only be managed individually through implantation

Yes I think this is the case – although in exemplar we can put an outline for what it looks like. aka

```auto
#include <version>

#if defined(__cpp_concepts) &&__cpp_concepts >= 201907L
// C++20 concepts supported
#elif __cplusplus < 202002L
#error “C++20 or later is required”
#endif

```

Unfortunately I’ve learned that MSVC doesn’t apparently reliably set the primary language feature test macros – so more precise feature macros like the concepts one here are needed for portability.

Note that scope is weird because of this temporary dependence on the experimental scope – which I plan to mostly break soon because the proposal is going to diverge from experimental soonish.

This issue is related btw: [Guidance for enforcement of minimum CXX\_STANDARD\_VERSION in libraries. · Issue #187 · bemanproject/beman · GitHub](https://github.com/bemanproject/beman/issues/187)