Should we include the target C++ version in repository names?

Beman Project Development
1

It occurred to me that it might be undesirable to put the names of the targeted C++ standard versions in the repository names because the targeted version might change. For example, if P2988 for whatever reason doesn’t make C++26, then we’ll have a project named optional26 that isn’t fully in C++26. Similarly, net29 might hypothetically not make C++29. I’d propose the following renamings:

  • net29 → net
  • execution26 → execution
  • optional26 → optional

This introduces the potential problem that, for example, a future Beman repository that makes changes to std::optional can’t also be called bemanproject/optional, but I’m okay with asking that hypothetical future repository to pick a more descriptive name instead of letting it rely on the targeted version to differentiate itself.

1 Like
2

Maybe bigger/ introductory projects like net or execution, they should not have a version attached to it.

But for smaller/ additive projects like optional, we could keep the version number.

A better way would be repos with more descriptive names:

  • optional_with_range
  • optional_ref
    But would be unrealistic to adopt in current stance.
3

I agree with @ednolan’s suggestion. A library’s deployment vehicle can change on a whim, and if we have to update the repo name every time this happens, it’ll be a nuisance for users.

2 Likes
4

It’s a breaking change, so we should do it now or not at all. But even given that, we should do it.
Optional26, implementing two proposals for 26 was hard to name.
Should optional<T&&> be in Optional29 now?

1 Like
5

Concur.

I’ve actually been worried about this and really haven’t said anything, but I think Eddie is right and the target version should really not be in the repo names. It’ll get too crufty too quickly as proposals miss the train.

1 Like