Add an explicit conversion operator from rust::Str
to std::string_view
.
#1486
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PTAL?
I am aware of #80 (adding a way to construct
rust::Str
fromstd::string_view
, using a custom C++17-detection mechanism) and #410 (adding a way to constructrust::String
fromstd::string_view
, also using a custom C++17 detection mechanism). But maybe we can still proceed with this PR given that:rust::Str
. I think that adding such an explicit operator has close to zero risk of breaking existing users (unlike the other PRs where new constructor overloads may risk ambiguity or other resolution problems)rust::Slice
to become a C++20contiguous_range
. #1432 added a (C++-20-specific) way to convertrust::Slice
into Chromium'sbase::span
(which neededrust::Slice
to expose a differentiterator_category
in C++20 than in earlier versions).char8_t
-related problem there). #1437 added CI coverage for different C++ versions.FWIW I've also noticed 5ae3a93 where
#if __cplusplus >= 202002L
was replaced with#ifdef __cpp_char8_t
. IIUC this is using https://en.cppreference.com/w/cpp/utility/feature_test which are available in C++20 and later. So I think we can't do that in this PR.