Status of std::string::insert_range

[Thomas Sepez]

I didn't see a listing for C++23 std::string::insert_range() in our Modern C++ readme.  

Is this currently allowed?

Should this be allowed?  

[Daniel Cheng]

A bit more generically, each new C++ version usually brings more convenience methods on various classes that have been around for a long time. For example, in C++20, we got std::string_view::starts_with(), but I don't think there was ever a discussion about allowing this. Do we usually consider these new convenience methods allowed by default if they're not otherwise mentioned?

Daniel

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAPYU9wR4oZDmxyZV7aooDcqmR76pyMJOV4jvm_vW80QFYPPcJg%40mail.gmail.com.

[Jan Wilken Dörrie]

> A bit more generically, each new C++ version usually brings more convenience methods on various classes that have been around for a long time. For example, in C++20, we got std::string_view::starts_with(), but I don't think there was ever a discussion about allowing this. Do we usually consider these new convenience methods allowed by default if they're not otherwise mentioned?

That would be my preference, yes. If we look at the library features added in C++23, I'd argue changes like 

> * Monadic operations (transform, or_else, and and_then) for std::optional (P0798R8)
> * std::tuple is compatible with other tuple-like objects (P2165R4)
> * Adding default arguments for std::pair's forwarding constructor (P2718R0)
> * Constructibility and assignability of containers from other compatible ranges (P1206R7)
> * Allowing iterator pair construction in std::stack and std::queue (P1425R4)
> * Heterogeneous erasure overloads for associative containers (P2077R2)
> 
> * constexpr support for
>   - std::bitset (P2417R2)
>   - std::unique_ptr (P2273R3)
>   - Some <cmath> functions (P0533R9)
> 
> * New member functions and changes in string types:
>   - std::basic_string::contains and std::basic_string_view::contains (P1679R3)
>   - Disabling construction from nullptr for std::basic_string and std::basic_string_view (P2166R1)
>   - Explicit range constructor for std::basic_string_view (P1989R2)
>   - std::basic_string::resize_and_overwrite (P1072R10)
>   - Rvalue reference overload of std::basic_string::substr for efficient slicing (P2438R2)

are trivial enough that they shouldn't each require a cxx@ thread. Maybe a guideline of changes to APIs to functions / classes that were already allowed prior to the new C++ version are allowed by default?

Then we could focus cxx@ threads on new language features (e.g. deducing this) and new library functions and classes (e.g. std::forward_like and std::expected).

Best,

Jan

[Thomas Sepez]

That would be great, however the concern has usually been whether such new features yield significantly worse code than the corresponding two-argument form. Fortunately, in this case, it may even yield better code.  Consensus from rest of the cxx folks on this?

[Daniel Cheng]

I think we should allow insert_range(). But our policy here seems to be quite inconsistent, e.g. std::string::contains() had an explicit discussion; std::optional::or_else() is also explicitly marked as banned atm. I'm not entirely sure why `or_else()` is specifically called out in https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md#library-review-23, while other things aren't.

Daniel

[Joe Mason]

It's not marked banned, it's marked "TBD".

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF3XrKoU%2B3yyEupL%2BojVcNw0f%3De0VsD0QNvAMaczZRZ3J%3DwB2w%40mail.gmail.com.

[Daniel Cheng]

Oops, sorry about that. The net result is the same though: you're not supposed to use TBD features :)

[Kyle Charbonneau]

 Do we usually consider these new convenience methods allowed by default if they're not otherwise mentioned?

 

I would support this. Restricting new methods on previously allowed STL types or new overloads of previously allowed STL functions seems a bit unrealistic. Many developers will use the functions/methods without realizing they were added in C++XX and could be banned. If problematic convenience methods or function overloads are added in a C++ release, we can still add them to the banned / TBD list.

Kyle

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF3XrKp%2BjfQnO9hMsRbgSqLTwTLB6XChddcgzBEdsAqo3H-36Q%40mail.gmail.com.