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.
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.
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?
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.