Repository navigation
proposal: strings: add Lines #51039
Description
Activity
Here are some other approaches I've seen while searching:
strings.Split(strings.ReplaceAll(s, "\r\n", "\n"), "\n")
regexp.MustCompile("\r?\n").Split(s, -1)
Assuming a "line" is anything delimited by one of
\n,\r, and\r\n, callingstrings.FieldsFuncwithfunc(c rune) bool { return c == '\n' || c == '\r' }seems to work.Reacted by Ilia Choly and CarlanaOh, right. It's actually just Fields. You want something that returns 4 strings for "text\n\n\ntext`, two of which are empty, which is different from what Fields does.
Reacted by Ilia CholyWhat about adding
strings.SplitFuncinstead? That would mirrorstrings.FieldsFuncand let you split on a custom function.What would the signature of the callback look like? Something like
func(rune) boolwouldn't be able to handle the\r\ncase.EDIT: right, that's probably why it doesn't exist. The API is less obvious. You'd need to check substrings instead of the single runes.
If something like
SplitMultiwas added, then you'd also need all the different variations. That gets messy.func SplitMulti(s, seps []string) []string func SplitMultiAfter(s, seps []string) []string func SplitMultiAfterN(s, seps []string, n int) []string func SplitMultiN(s, seps []string, n int) []string
- changed the title
[-]proposal: strings: add Lines func[/-][+]strings: add Lines[/+]on Feb 15, 2022 Cut works great.
for text != "" { line, rest, ok := strings.Cut(text, "\n") text = rest line = strings.TrimSuffix(line, "\r") // if you care ... use line ... }Reacted by Ilia Choly and Ingo OeserFor that matter, strings.SplitAfter(text, "\n") also works.
There's an extra empty string at the end of the slice if the text ends in a final \n (as most do).This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group3 remaining items
Since you have that, how are you ending up with a string in memory that may have windows line endings?
@jimmyfrasche Say you're working with an AST which exposes comments as multiline strings.
Reacted by jimmyfrascheIt sounds like (1) the API is somewhat inefficient since it has to allocate the slice, (2) there are other ways to write the code that are more efficient and just as clean using existing standard library APIs, and (3) this could be in an external library easily instead if the exact operation of 'return a slice of all the lines' is required.
In that case, it seems like this is heading toward likely decline. Do I have that right?
(1) the API is somewhat inefficient since it has to allocate the slice,
Given the target use-cases, this would be negligible.
(2) there are other ways to write the code that are more efficient and just as clean using existing standard library APIs
I'm not sure about "just as clean". The proposed
strings.Linesapi is more ergonomic than other solutions.(3) this could be in an external library easily instead if the exact operation of 'return a slice of all the lines' is required.
ofc
In that case, it seems like this is heading toward likely decline. Do I have that right?
Ya, I think so. The potential for abuse makes it not worth it IMO.
Given the target use-cases, this would be negligible.
The problem with putting things in the standard library is that it will get used for many uses cases beyond the target. Things in the standard library have to be particularly robust against unexpected uses.
Reacted by Ilia CholyBased on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group- locked and limited conversation to collaborators
on Mar 9, 2023
If I already have a string in memory, there's no simple and efficient way of splitting it into lines.
The naïve approach won't handle
\r\n.Using a
bufio.Scannerworks but it creates copies instead of slicing the existing string.I'd like a new
strings.Linesfunction similar tostrings.Fieldsfor this use-case.