Ruben Perez wrote:
So my suggestion is to create a separate library/repo, Boost.Compat (boostorg/compat, namespace boost::compat) for them.
Thoughts? (Be sure to read the discussion in the PR as well.)
I'm in favor of this. I agree with not allowing extensions, too.
I think a light review should take place before inclusion.
The suggested repository is now ready for light review at https://github.com/boostorg/compat, complete with its first component, an implementation of std::latch by Christian Mazakas. Everyone's light reviews are welcome.
On 17/05/2023 13:44, Vinnie Falco wrote:
On Tue, May 16, 2023 at 6:37 PM Peter Dimov wrote:
It reads the README
Oh.. wow, that is incredibly restrictive. No public types? Uhhhhh
Technically I think those rules don't preclude making a public string_view in your own library that uses a Boost.Compat string_view either via private inheritance or composition. Having said that, I'm not sure that obeys the spirit of the rules, or that it's a good idea to proliferate such duplicates even if so; it would lead to aggravating type incompatibility (which already exists with multiple independent implementations [e.g. optional, shared_ptr, and the existing string_view], but is somehow worse when those multiple top-level types actually use the same underlying implementation but are still otherwise type-incompatible). Which is probably a good justification for not making a Boost.Compat string_view or similar in the first place, although this does limit utility. It does perhaps beg the question of why the latch couldn't be in a detail namespace of Boost.Utility (or Boost.Detail, for that matter) instead of a new library instead. Inevitably *some* user code is going to find a Boost.Compat type and start using it directly, README notwithstanding.
Gavin Lambert wrote:
It does perhaps beg the question of why the latch couldn't be in a detail namespace of Boost.Utility (or Boost.Detail, for that matter)
Things in detail namespaces don't have tests or docs and are not intended to be used outside of their respective libraries. Boost.Detail is an oxymoron and shouldn't exist.
instead of a new library instead. Inevitably *some* user code is going to find a Boost.Compat type and start using it directly, README notwithstanding.
That's not a problem. The rules in the README are intended to limit the scope of the library (to tell us what types belong there), not to stop users from using the types.
On 5/16/23 7:20 PM, Peter Dimov via Boost wrote:
Gavin Lambert wrote:
It does perhaps beg the question of why the latch couldn't be in a detail namespace of Boost.Utility (or Boost.Detail, for that matter)
Things in detail namespaces don't have tests or docs and are not intended to be used outside of their respective libraries.
Boost.Detail is an oxymoron and shouldn't exist.
a little history here. many, many years ago, the serialization library need an io facet for handling utf characters. This was not a trivial thing and information on how to do was not so widely available. Ron Garcia had written one and it was incorporated into the serialization library as well as at least one other library. No one really wanted to take responsibility for it. That is add documentation, submit to review etc, etc. It didn't belong to any particular library. The consensus at the time was to put it into a "detail" library. It's been a PITA ever since. Robert Ramey
We could maybe solve the publicity issue by having the implementation become a typedef when the header is available. This creates ABI issues when linking against binary archives but at least maintains API compatibility, i.e. a user who wrote a function taking boost::compat::latch can pass a std::latch in C++20 mode.
From my own experiences, this seems to be in line with what users actually want, where Boost's polyfills become their stdlib counterparts when available.
No one's said anything about the quality of the implementation or the tests, which is worrisome to me. - Christian
On Thu, May 18, 2023 at 5:31 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
We could maybe solve the publicity issue by having the implementation become a typedef when the header is available.
I'm fine with this, but if we go this route it might be better that Compat depend on no other Boost libraries. e.g. They wouldn't be able to count on the features of Boost.Assert.
From my own experiences, this seems to be in line with what users actually want, where Boost's polyfills become their stdlib counterparts when available.
Yes, this appears to be the increasingly prevailing desire. Glen
Glen Fernandes wrote:
On Thu, May 18, 2023 at 5:31 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
We could maybe solve the publicity issue by having the implementation become a typedef when the header is available.
What "publicity issue"?
I'm fine with this, but if we go this route it might be better that Compat depend on no other Boost libraries.
e.g. They wouldn't be able to count on the features of Boost.Assert.
No, Boost libraries should never use `assert` or `throw` directly (unless they duplicate the relevant functionality of Assert and ThrowException.) Note that an implementation consisting of e.g. `using std::latch;` does not use `assert` or `throw` so it doesn't violate the above rule. Interestingly, said implementation would actually fail our current latch_test.cpp which uses BOOST_ENABLE_ASSERT_HANDLER to check precondition violations, but we'll fix that test if we ever switch to it.
What "publicity issue"?
Sorry for being ambiguous here. I meant the idea that Compat types shouldn't appear in public interfaces. In general, a user is going to want to use Compat because they still want to or must support C++11 while still using modern C++ types and practices. It helps users the most to permit and encourage Compat types in interfaces with the understanding that they become typedefs when the appropriate library support is there. To this end, a user can write a C++11 library using `boost::compat::span` and then seamlessly transition to using it with `std::span` in C++20 mode. In my experience, this is what most people expect and want from a compat library like what's being proposed. And because pre-C++20 has so much developer market share, I think there's tremendous value in a library like Compat. - Christian
On Fri, May 19, 2023 at 9:00 AM Christian Mazakas via Boost
In general, a user is going to want to use Compat...
But if I am reading the description of the library correctly, Compat is not for "users." Or rather, the intended "users" of Compat are other Boost libraries only. Thanks
Christian Mazakas wrote:
What "publicity issue"?
Sorry for being ambiguous here.
I meant the idea that Compat types shouldn't appear in public interfaces.
That's not quite the intent. Types intended to appear in public interfaces don't go into Compat. This means that string_view, span, and similar types do not go into Compat. This rule is often unnecessary because interface types such as string_view don't meet the other criterion, that they must match their standard equivalents exactly. boost::core::string_view for example doesn't, because it allows implicit conversions from and to std::string_view.
To this end, a user can write a C++11 library using `boost::compat::span` and then seamlessly transition to using it with `std::span` in C++20 mode.
The user can't do this because there is no boost::compat::span. span is in Core.
The suggested repository is now ready for light review at https://github.com/boostorg/compat, complete with its first component, an implementation of std::latch by Christian Mazakas.
Everyone's light reviews are welcome.
If there are no objections I'll go ahead with adding boostorg/compat as a submodule.
participants (6)
-
Christian Mazakas -
Gavin Lambert -
Glen Fernandes -
Peter Dimov -
Robert Ramey -
Vinnie Falco