@SamareshSingh, who has been active in the sync has made his first major contribution with an implementation of GitHub - bemanproject/span: A Beman implementation of std::span (C++20) and contributes to bemanproject/beman#198 · GitHub . I’ve done some initial reviews and experiments and it looks good so far.
There’s a handful of papers to improve span in both 26 and 29. I find span to be an immensly useful tool in everyday production tool so I’m thrilled we have in implementation that we can experiment with and improve this library. Thanks again @SamareshSingh !
2 Likes
This is great! Thanks for this contribution @SamareshSingh.
Would you be willing to accept PRs that make this usable from C++17? I think it’ll be relatively minimal.
I was encouraging the other direction so he didn’t have to jump through enable_if hoops – but I can understand why you’d want this 
What would be the purpose of beman.span?
See the repo – there’s several proposed new features for span and the repo implements them.
I was looking at the README but it doesn’t list the new features it implements. It does link to cppreference, which says that at is a C++26 feature, so I assumed this was one of them.
Although on second look, it also links to Create an implementation of span · Issue #198 · bemanproject/beman · GitHub which in its last comment has links to PRs with the new features.
Anyway. The reason this is interesting is that the Beman lifecycle says that a Beman library is retired two cycles after it’s accepted into the standard. But span was accepted in C++20, so it would have been retired in 2026. So this is an interesting example of why the lifecycle doesn’t quite work in practice; a standard component may get (and in fact they do get) additions three or four cycles later, sometimes even five or six cycles later.
yep, fair point. The map api changes will be in the same boat. And, in fact we ended up having that discussion yesterday (we’re at c++now currently). We basically settled on the idea that well we could retire something and then if needed “unretire it” if there’s a need to add new features. Also, we can change our policy if there’s widespread demand for something to stay officially in Beman. But to be clear, the intent was never to kill the repo even if it’s in a retired state.
One other related discussion that came up is should libraries have a switch that uses the std:: version by default if it’s available. That might have usability concerns, but something we should consider non-the-less.
This can easily become a problem if done for an interface type like span, because now a library API can change depending on whether it’s compiled with or without the switch.
We’ve been over these same things in Boost, and there are no easy answers.