On 2/8/24 18:54, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 2/8/24 18:14, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Which they are not, as boost::core::string_view doesn't support char_traits. So it looks like a non-starter to me.
Do you really need or support traits other than std::char_traits<Ch>? Why and where?
It's not that I need it. It's that std::basic_string(_view) are defined this way (for better or worse), and for our string_view to properly emulate and inperoperate with std::string_view, it should have it as well.
That's not true at all.
You're not winning anything by not supporting it either as you're using std::char_traits internally anyway.
core::string_view is intended to be used in this manner:
void my_api_function( core::string_view sv );
which then allows the user to pass std::string, std::string_view, boost::string_view.
It's not intended to be used in this manner
template<class Ch> void my_api_function( core::basic_string_view<Ch> sv );
because then conversions don't work.
There is no benefit in also supporting
template
void my_api_function( core::basic_string_view sv ); because it doesn't work either.
This implies that the API only works with one character type, which is not always the case, as shown in Boost.Log. Template interface parity is useful in cases like this: https://github.com/boostorg/container/blob/6e697d796897b32b471b4f0740dcaa03d... https://github.com/boostorg/container/blob/6e697d796897b32b471b4f0740dcaa03d... It also allows to interoperate with strings with custom char traits just in case if someone actually uses them.