Standardized C++ version expression as a language proposal

Suggested by @bretbrownjr

A new beman library and paper for a C++ language feature for “cxx_minimum_required(17)”, syntax negotiable

Name pending.

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

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.

1 Like

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

beman.policy?

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.

Which we already have.

#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.

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 for details”.

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

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

Naming is hard.

What’s the conflict?

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