Josh Goebel

> If we are in the middle of an UTF-8 char operator[_] should handle it somehow (or bomb which would be saner than what we currently have). You mean add...

> If you mean indexing on String, indices are bytes. Yes, right, I read that... but the behavior around "half-characters" is what's causing this bug. ``` __buffered = __buffered[lineSeparator +...

Personally I find the string tests easier to read than the byte value tests... from the tests though I can't tell that any behavior changed here? Looks like it's doing...

Yeah I think I see now, it just was very confusing that the entire format of the tests also changed so you can't look at the tests diff at a...

So this patch would actually resolve the whole issue here I think... but PERHAPS introduce the problem where someone calling `readLine` would blow up because they retrieved invalid UTF-8... (I'm...

> if there was legitimate invalid chars in the middle of the sequence they would have bin previously silently removed. I don't follow this and I'm not sure what a...

> the fact that we have bytes indexing in String is a not really logical to me, Agree, it's more than a tad bit confusion.

> and provide the new one via StringByteSequence operator [_] Doesn't that already work? The problem this issue is raising is that StringByteSequence is being used for `readBytes` where-as the...

> StringByteSequence operator [_] Does not work with range because smart index returns the byte as Num. I guess I'm not sure why we need it to? _It would really...

I may have to bow out of this one. I thought I could solve it by storing a list of strings/packets as they arrive, but you end up left with...