I’m fairly certain at this point that P1028 status_code (https://wg21.link/P1028) will not make it into C++ 26, and I’m moving on from LEWG after C++ 26 major features close. My last in person meeting will be Sofia 2026, and I’ll say farewell to you all in person then.
Would the Beman Project like to take ownership of the reference implementation at GitHub - ned14/status-code: Proposed SG14 status_code for the C++ standard? I’m happy to maintain it, it ships with Boost after all. But I’m done with LEWG’s inability to take the tough decisions needed to standardise that library, so I won’t be championing it going forth.
Absolutely happy for others to take over championing it. It is possibly one of the most popular and widely deployed C++ 11 library designs of the past decade. If standardisation has anything to do with existing practice, here is your gold standard case example of that.
Welcome @ned14! If I understand it, status_code hasn’t been rejected in any way by the committee so it seems in scope for the Beman project if you’re interested in incorporating it.
We should be able to find someone willing to champion in WG21 it at any rate. It’s a good proposal!
Putting it in the beman org sounds like good to me. You should be able to do this now. Check out the Beman Standard to figure out how to make library conform.
I think all those requirements are fine bar one: I can’t rename the include path which is currently status_code to Beman/StatusCode. Otherwise all existing code based on Standalone Outcome and Boost.Outcome would break.
I am a little surprised about the CamelCase naming given the standards focus, but I also don’t really care. I do care very much about breaking existing codebases unless there is an exceptionally good reason.
We may want to revisit it, especially with the combination of the allergic reaction of WG21 to CapitalLetters (see Concepts all getting renamed) and the existence of case insensitive file systems which means that include/Beman and include/beman are identical.
C has started using capital letters, but only because they’re using _Ugly names for new things, and had already reserved ^_[A-Z] as implementation namespace.
For a new library, CamelCase ensures no future collision with a standard library header of the same name. So I get the rationale.
I’m not opposed to symbolic links, though I’d then worry what happens when a package manager installs status_code because it would then add Beman links and that might be problematic.
Incidentally status_code has been shipping in the three major C++ package managers for many years now, and we also have to be careful to not break them either. I get complaints if I ever change anything!
Would allowing for both ways to include the header work for you? The intent of the standard was to require a Beman/ header, but not prevent other headers for backwards compatibility or separate branding.
So there would be a include/Beman/status_code.hpp which includes include/status_code/status_code.hpp? If so, that would work for me.
As a wider thought though, are you sure that a monolithic representation is the right call for the Beman collection of libraries?
I’m sure you’ve all discussed this to death, so I don’t wish to relitigate. However, me personally, I always felt that Boost putting everything into boost/* was a mistake. They should have put “Boost Core” into boost/*, and clearly non-core Boost libraries should have gone into their own header prefix.
For example, Boost.Regex I would say has absolutely no business being in Core. It’s a regex library. It has a highly non trivial implementation.
Whereas something like Boost.CallTraits, that’s a good candidate for Core, so it would have a boost/ prefix.
Boost has fairly obviously three category of library: (i) clearly core (i) possibly-core (iii) clearly niche. Me personally, I think the Beman libraries ought to disambiguate between those three categories in namespacing and include path naming. In my opinion, that will help prevent the rats nest of interdependencies which arose in Boost, which are acceptable within Core, less so in possibly-core, and not acceptable in niche libraries.
So there would be a include/Beman/status_code.hpp which includes include/status_code/status_code.hpp? If so, that would work for me.
That seems right.
sure that a monolithic representation
putting everything into boost/*was a mistake
It’s a good point because one thing for sure we want every library to be able to stand on it’s own – the antithesis of the boost monolith. So there’s a bit of tradeoff here that when we package several libs together the include path simplifies things for users of the libraries when using in the Beman context. That said, it’s early days in this project so nothing is 100% set in concrete.
Beman is currently treating each library as an independent entity so there is no “core” to speak of. The drawback is longer (and sometimes redundant) include paths (e.g. #include <Beman/InplaceVector/inplace_vector.hpp>) and names (e.g. Beman::InplaceVector::inplace_vector). I think this is a reasonable tradeoff to avoid debate over what is core and allows for competing proposals to co-exist (Beman::RegularSimd vs. Beman::SimdThatDavidDislikes) .
.