add std.string.splitterLines()

[WalterBright]

Melds together string.splitLines() and algorithm.splitter() to make a line splitter that doesn't allocate memory and accepts ranges as input instead of just arrays.

[andralex]

Not a fan of superlong if statements - this is virtually the entire function. Have it call a helper function? Or make an early return?

[WalterBright]

Because of branch prediction, the 'then' is the hot case, and this is why it is organized as it is. Performance! The 'then' is complex enough that as a helper function, it would not get inlined.

[andralex]

You won't be able to measure a difference for this one test in such a large function.

Functions consisting of essentially one if are the pits. The reader sees the beginning of a bulky if and goes, "boy that's some good long if statement, surely this function will do many wonderful interesting things long after this if is done". So the reader puts the if on the mental stack and goes on to read the large body of code inside the if, to just realize much later that all that was for naught - there's nothing after if so it needn't be remembered in the first place!

This is not good style, pure and simple. It's not reason enough to reject this code, but you'd do good to refactor it and anyone coming later would do good to refactor it.

[burner]

can you transform the nogc test into a doc unittest. Examples always help.

[burner]

I'm not a native english speaker, but I believe both "Does .." sentences need a subject.

[mdparker]

That's actually a common usage when describing how something works. The subject is implied -- though we don't use it in conversation.

[Panke]

LGTM.

[andralex]

An iteration would be nice here - after that we can pull this.

static immutable witness = ["peter", "paul", "jerry", "\u2028ice\u2029cream", "sunday", "mon\u2030day"];
uint i;
foreach (line; lines)
{
    assert(line == witness[i++]);
} 
assert(i == 6);

[andralex]

Auto-merge toggled on

[schuetzm]

I see it's already merged, but I'd like to bikeshed: splitterLines sounds awkward. How about linesSplitter or lineSplitter?

[Poita]

Have to agree, the name really isn't great. Can we overload byLine? It shouldn't conflict, right?

[Hackerpilot]

I also think that lineSplitter would be more clear. Walter even called it "line splitter" in his original comment.

[quickfur]

👍 for lineSplitter. splitterLines sounds really poor.

[JakobOvrum]

Requiring length seriously limits this algorithm. It can't support infinite ranges, nor ranges with unknown length, such as data coming from a socket.

[kuettler]

It requires slicing. Are there ranges without length that support slicing? Without allocating memory? There is splitLines and std.algorithm.splitter for such purposes, right?

[kuettler]

Also, given the functions splitLines and std.algorithm.splitter, the name splitterLines might not be so bad. I like to think of range functions as functions rather than object. lineSplitter is not a nice name for a function.

[schuetzm]

@kuettler Infinite ranges can support slicing, but they don't have a (finite) length.

[ntrel]

@kuettler We already have splitter which is a function, it acts like a constructor for a type. Assuming that name is OK, lineSplitter seems logical for this pull.

@Poita:

Can we overload byLine? It shouldn't conflict, right?

Maybe, but std.stdio.byLine doesn't handle all kinds of newline separators (you have to pick only one), so IMO it would be confusing to have the same name for things that have different semantics.

[burner]

@WalterBright what is the reason for this alias? is size_t not suitable here?

[JakobOvrum]

It's murky territory. For example, the length property is allowed to always return ulong (according to hasLength), which breaks code that assumes size_t when the target is a 32-bit platform. Yet many range algorithms and higher-order ranges treat the length property as being size_t. I don't think it's a major problem, but in the long term we need to settle on which way to go.