Potential Policy Change: Making C++20 the minimum library implementation

Beman Project Development
1

During the review of indirect today the horror of all the c++17 ifdef’s to make up for the lack of concepts was everywhere. Given that new Beman libraries should be targeting c++29 and beyond, many people thought that going forward c++20 should be the minimum standard. This would match with the two cycle library retirement policy.

Proposed policy:

[cpp.minimum-version]
**Requirement**: Libraries should use a minimum of C++20 for 
implementation and avoid C++17 patterns such as `enable_if`
1 Like
2

Reasonably strong disagree from me. I’d want a policy that says what version we’re expected to support, and leaving it to individual libraries if they want to go beyond. If it’s a lot of noise it’s likely not useful, but for some libraries it can be a small enough amount of work and offer c++17 users (like most of automotive still is - in part because of MISRA C++ 23 being based on it, and AUTOSAR on that) the ability to polyfill.

3

Ok. I don’t think there can be a universal minimum support version. By that I mean if someone brings a reflection based library it necessarily will apply to 26 and above.

The Beman project isn’t responsible for the fact that these standards actively harm their users by preventing them from upgrading to safer standards. It is also, at least not currently, our mission to provide polyfill for older standards. Rather it is to improve the input for future standards.

I’d also note that independent of the mission arguments, holding on to older standards means a larger CI matrix.

4

This is a great change!

Without std::is_constant_evaluated(), proper implementations of some Beman features utterly impossible anyway (not considering compiler extensions). At least I couldn’t imagine beman.big_int without C++20.

That being said, if it’s easy to provide C++17 support or lower, I don’t see a strong reason not to just do it. It’s definitely unusual for proposals and Beman libraries at this point though.

5

Thanks for the input. I think for most Beman libraries trying to go without concepts really complicates things, but your example is another one.

Right now I’m thinking we should make it a recommendation instead of a requirement since there’s several voices suggesting they want the option of the backward look – certainly that’s the case for indirect.

6

I’ve gone ahead and opened a couple of issues to make 20 a recommendation.

1 Like
7

I personally feel that we should ban C++17 support, at least in main (if maintainers want to have a separate cpp17 branch or a fork, that’s fine).

Our experience from the review process for beman.indirect at C++Now this year was that the #if BEMAN_INDIRECT_USE_CONCEPTS code made the library significantly more cumbersome to review.

Beman libraries aren’t normal libraries. The main goal of a normal library is to be the most useful version of that library that it can be. The main goal of a Beman library is to improve the paper, and I think this is a case where what we want is a less featureful library that nonetheless serves as a more useful vehicle for paper feedback. C++17 support might allow for wider field experience, but the resulting feedback is based on what’s essentially a weird compatibility fork of the paper, not the code that is actually being proposed for standardization. To me, any benefits we get there are outweighed by the empirically increased difficulty of code review that comes from adding these polyfills.

1 Like
8

I strongly disagree with these proposals.

Yes, it would make the code of a few libraries less of a toil to review if we ban C++17 support. However, there are other impacts of adopting such a policy:

  1. Fewer Beman library authors. I wrote beman.indirect because I’d like it to be used where I work (Adobe) which, for fundamental libraries like this, needs to support some older compilers/flags. If I need to maintain two branches or wouldn’t be allowed to submit this to the Beman project, I wouldn’t bother.
  2. Fewer Beman library users. 49% of C++ developers are not free to use C++20 according to the survey just released on isocpp.org. While I certainly think it should be the author’s discretion as to what they support, having a policy that automatically cuts out half of C++ users for all libraries is loosing sight of the big picture.
  3. Inserting bias towards companies with small or centrally controlled codebases. The people in support of the change, of course, are already on C++20 or newer. Optimizing for a self-selected subset of the C++ population is a problem ISO C++ already has and this would exacerbate it. To make good decisions, we need feedback from the WHOLE community, not just those on the bleeding edge.

The actual code (where the complexity lies) is the least interesting part of a review. The important review comments are on the interface/documentation. Making a library more accessible is the best way to get more useful feedback. Don’t prevent contributors from volunteering to do that!

1 Like
9

I agree with David’s points here. I feel that any wording around a minimum standard version should use “encourage” or “discourage”, not “require” or “ban.” Beman should be flexible when it invites a larger community to get involved.