Utility Libraries

In beman.utf_view I’ve got code that provides implementations of iterators across various iterator categories for the purpose of unit testing.

Steve Downey mentioned that he was interested in having a library like this for some of his own testing.

However, test_iterators can’t currently be a Beman library because it doesn’t (and shouldn’t) have an associated paper.

I think this situation is going to come up more often and we should have a system for dealing with it.

My idea is that we should have a category of libraries called “utility libraries.” These are libraries that are useful as implementation details of a paper’s reference implementation, but which don’t have associated papers themselves.

Differences from traditional Beman libraries would include:

  • The library name would need to be prefixed with util_, e.g., beman.util_test_iterators
  • In order to avoid excessive burden on the review pipeline, and because we don’t want to require maintainers to support non-Beman users for these, the libraries would not be subject to the Beman Library Maturity Model (exempting them from the “library status” part of [readme.badges], and from [readme.library_status])
  • They would also be exempt from the [readme.implements] Beman Standard rule, since there’s no associated paper

Otherwise, they’d work the same as other Beman libraries.

We could also imagine having a rule that utility libraries need to be consumed by at least one downstream non-utility library (transitively, so utility → utility → non-utility would also be okay).

1 Like

Good versions of some common test utilities would be in scope for something in this space.

Like types that have the various combinations of constructors and assignments to ease the burden of remembering to test a move only with deleted assignment type (not that it’s sensible, just that it’s legal…).

It seems that input ranges are not as intrinsically hostile as we first thought, but having ones that strictly model the concept, even if they are just using aliases for std:: components might help with clarity of intent?

The constify hack, putting the arguments in a manifestly const eval context, might be useful, too?