Standardized C++ version expression as a language proposal

Beman Libraries
1

Suggested by @bretbrownjr

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

Name pending.

2

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

3

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
4

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

beman.policy?

5

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.

6

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.

7

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?

8

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

Naming is hard.

9

What’s the conflict?

10

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

11

What about beman.minimum_required?

12

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
13

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
14

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

// 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

15

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

#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