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, calling strings.FieldsFunc with func(c rune) bool { return c == '\n' || c == '\r' } seems to work.

@ALTree thanks, I'll be using that. However, it doesn't give the correct output for strings with blank lines like "\n\n\n"

Oh, 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.

What about adding strings.SplitFunc instead? That would mirror strings.FieldsFunc and let you split on a custom function.

What would the signature of the callback look like? Something like func(rune) bool wouldn't be able to handle the \r\n case.

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 SplitMulti was 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

Cut works great.

for text != "" {
   line, rest, ok := strings.Cut(text, "\n")
   text = rest
   line = strings.TrimSuffix(line, "\r") // if you care
   ... use line ...
}

For 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 group

One potential problem with strings.Lines is that it might encourage people to write inefficient code.

data, _ := os.ReadFile("lines.txt)
for _, line := range strings.Lines(string(data)) {
  // use line
}

Having a reader and writers that transform line endings would be great. (Or, if https://pkg.go.dev/golang.org/x/text/transform were in std, they could just be transformers.)

@jimmyfrasche can be done with https://pkg.go.dev/github.com/icholy/replace

t := replace.String("\r\n", "\n")

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.

It 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.Lines api 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.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group