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.

What about beman.minimum_required?

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.

1 Like

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.

1 Like