Re: [boost] Should boost::core::string_view be made public?
Have you come to a conclusion how this should be handled (in the future)? The problem is basically that there are different implementations for string_view. I don't know why it was done this way. Presumably it's because various boost libraries want to be independent of others, so that some things are implemented anew each time (within the library) instead of using existing libraries. This will also be due to the fact that boost is not atomistic enough, so that large libraries might have to be included/used, although only a fraction of the functionality is needed. My suggestion: - Throw out boost::utility::string_view - Make boost::core::detail::string_view public, just like all other backports in boost::core. - Check if there are other multiple implementations. If so, pull them out into separate small boost libraries. (For databases, this would be called normalization, but it must not be over-normalized). regards Gero
g.peterhoff--- wrote:
Have you come to a conclusion how this should be handled (in the future)?
The problem is basically that there are different implementations for string_view. I don't know why it was done this way.
The motivation for creating boost::core::string_view was that there exist several pre-C++17 Boost libraries that want to take and return string views as parameters and return values. This is a problem because C++17 users prefer to use std::string_view. These libraries used to offer a configuration macro that switched between boost::string_view and std::string_view (e.g. BOOST_LIBNAME_USE_STD_STRING_VIEW.) But this is also a problem because, since these libraries are compiled, users of precompiled libraries get one or the other. Their defining the macro cannot affect how the library has been built. That is why I created boost::core::string_view, which is a string view type that is also convertible from and to std::string_view. So the library API can be boost::core::string_view api_function( boost::core::string_view key ); but C++17 users can both pass std::string_view to it and store the return value into std::string_view. There have been attempts to add these conversions to boost::string_view, but those have been rejected by the maintainer. When I tried to add boost::core::string_view to Core as a documented and public component, people here objected. So it's not documented and public now. Hope those people are happy for heroically preventing components from being documented. So we are where we are.
чт, 15 февр. 2024 г. в 01:43, g.peterhoff--- via Boost <boost@lists.boost.org>:
My suggestion: - Throw out boost::utility::string_view - Make boost::core::detail::string_view public, just like all other backports in boost::core. - Check if there are other multiple implementations. If so, pull them out into separate small boost libraries. (For databases, this would be called normalization, but it must not be over-normalized).
I did not suggest replacing `string_view` with `core::string_view` because I know that neither has a superset of features. Because some libraries do use features `core::string_view`, replacing one with the other seems too disruptive. Sadly, most of this thread is a discussion of such replacement, and not what I was asking about. So, given that a replacement cannot happen today, should we make the type public so that I and other library maintainers could refer to it in the docs?
On Sat, Feb 17, 2024 at 1:58 PM Дмитрий Архипов wrote:
I did not suggest replacing `string_view` with `core::string_view` because I know that neither has a superset of features. Sadly, most of this thread is a discussion of such replacement, and not what I was asking about.
It's natural that people want to know why one can't be made into a superset. (i.e. They don't know why Boost can't have just one public string view type) Glen
On 17.02.24 19:58, Дмитрий Архипов via Boost wrote:
чт, 15 февр. 2024 г. в 01:43, g.peterhoff--- via Boost <boost@lists.boost.org>:
My suggestion: - Throw out boost::utility::string_view - Make boost::core::detail::string_view public, just like all other backports in boost::core. - Check if there are other multiple implementations. If so, pull them out into separate small boost libraries. (For databases, this would be called normalization, but it must not be over-normalized).
I did not suggest replacing `string_view` with `core::string_view` because I know that neither has a superset of features. Because some libraries do use features `core::string_view`, replacing one with the other seems too disruptive. Sadly, most of this thread is a discussion of such replacement, and not what I was asking about.
So, given that a replacement cannot happen today, should we make the type public so that I and other library maintainers could refer to it in the docs?
As an end user, I absolutely need to be aware of core::string_view, so I absolutely want it documented. Automatic conversion to std::string_view is useful, but it only happens in very limited contexts, so I can't just pretend that a core::string_view is really a std::string_view. -- Rainer Deyke (rainerd@eldwood.com)
participants (5)
-
g.peterhoff＠t-online.de -
Glen Fernandes -
Peter Dimov -
Rainer Deyke -
Дмитрий Архипов