P2210R0: Superior String Splitting

2020-12-14 Library Evolution Telecon Minutes

Chair: Ben Craig

Champion: Barry Revzin

Minute Taker: Inbal Levi

Start: 2020-12-14 08:05 Pacific Standard

POLL: We should promise more committee time to pursuing ranges string splitting, knowing that our time is scarce and this will leave less time for other work.

Attendance: 26 (27 at the end)

# of Authors: 1

Author Position: SF

Outcome: Consensus to pursue

POLL: Attempt to push P2210 changes into the IS prior to implementers providing a working split_view (with that name). (This requires Barry to provide papers quickly).

Attendance: 27

# of Authors: 1

Author Position: SF

Outcome: Barry should bring a paper back sooner rather than later.
End: 08:50

SUMMARY:
split_view's most important use case is for splitting strings, but the C++20 split_view is not currently well suited to that task.
The room is interested in fixing this use case. This would be a breaking change from C++20 in theory, but if the change happens quickly enough, then it won't be a breaking change in practice, as there aren't usable implementations in the wild.

OUTCOME: The author should return soon with a paper that has wording. The paper should discuss the tradeoffs between changing behavior vs. providing a new facility. Have an LWG wordsmith preview the wording so that it is suitable for forwarding / polling to forward.

P2210R1 Superior String Splitting (Barry Revzin)

I stumbled onto this topic after watching a 2017 lecture by Bjarne Stroustrup where he wishes C++ would have an easy way to split strings, like other languages. See https://www.youtube.com/watch?v=fX2W3nNjJIo at 1:12:20. He says that easy string splitting among other things are needed to give C++ broader appeal and a successful future for the next generation of programmers.

The current method with range views is anything but easy. Barry Revzin's proposal looks like a massive improvement. Thank you for all the heavy work involved in this. I sincerely hope a resolution is reached and the standard revised so that we get a usable string splitter in C++.

The revised proposal sounds good, which is to rename the less-useful current implementation to "lazy", and adding some variation of Revzin's improved code to the library instead. Preferably without any cruft related to the old, less-useful lazy version. A new, efficient revision of the entire function is better, since most people will be using it to split strings. And the old "more general range-related" one relegated to the "lazy" renaming.

Hi @Bananaman, thanks for the input. We don't use these GitHub issues for discussion of papers; we just use them to track status. But I'll ping @brevzin so he sees your feedback!

2021-02-02 Library Evolution Telecon

P2210R1: Superior String Splitting

2021-02-02 Library Evolution Telecon Minutes

POLL: Send P2210R1 (Superior String Splitting) to electronic balloting to be forwarded to LWG for C++23 (Bucket 2, improvement) with the intention to retroactively apply the paper to C++20.

Attendance: 34

# of Authors: 1

Author Position: SF

Outcome: Strong Consensus

POLL: P2210 Should add a feature test macro

Attendance: 33

# of Authors: 1

Author Position: WA

Outcome: No consensus

POLL: P2210 Should bump the value of a feature test macro

Attendance: 33

# of Authors: 1

Author Position: N

Outcome: No consensus

Summary

This paper proposes to improve views::split (and ranges::split_view) so that it works better for the important use case of splitting strings. The fix is backwards incompatible to what was published in C++20, however no implementation ships a production ready version yet, so we want to apply this fix before the status quo of C++20 will cause problems. We discussed if this change warrants a feature test macro, however there was no consensus for it, since we do not envision the in-between state that could be detected that way to ever ship in an implementation.

The old behaviour is still available under the new name views::lazy_split. There was some discussion about that name, however no serious suggestions came up. A different name will be considered iff it comes with strong rationale in form of a paper.

Outcome

The paper was forwarded to the Library Working Group, and to Electronic Polling with strong consensus.