P2210 Superior String Splitting

[wg21bot]

P2210R0 Superior String Splitting (Barry Revzin)

[ben-craig]

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	9	3	0	0

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).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	9	3	0	0

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.

[wg21bot]

P2210R1 Superior String Splitting (Barry Revzin)

[Arcitec]

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.

[brycelelbach]

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!

[brycelelbach]

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
16	4	2	0	0

Attendance: 34

# of Authors: 1

Author Position: SF

Outcome: Strong Consensus

POLL: P2210 Should add a feature test macro

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	2	5	7	1

Attendance: 33

# of Authors: 1

Author Position: WA

Outcome: No consensus

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	1	9	7	2

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.