What is the correct behavior of `Stdin.readLine`?

[joshgoebel]

I'm been working on an underlying Stream abstraction that we can use more broadly (STDIN, STDOUT, STDERR, Files, Network, etc)... and in trying to implement Stdin I'm realizing there may be some inconsistent behavior that we need to sort thru.

There is a TODO that readByte might be broken (and I'd say it is)... but I also see potential problems withreadLine.

• Traditionally the API awaits until there is a full line in the buffer
• If STDIN is closed during reading then anything in the read buffer is returned, (including an empty string)

Is this the correct behavior? It seems this makes it impossible to distinguish between inputs such as:

• data\nbob\n\n (3 lines)
• data\nbob\n (2 lines)

The result of calling readLine in a loop will always be 3 lines:

• "data"
• "bob"
• ""

IE, in the second case it appears an extra "line" has been added. Perhaps null should be returned when EOF is found (rather than aborting)... so then the inputs above would appear as:

data\nbob\n\n (3 lines)

• "data"
• "bob"
• ""
• null
• null, ...

data\nbob\n (2 lines)

• "data"
• "bob"
• null
• null, ...

---

There is also the question of what to do with an unterminated line (which can also have ambiguous behavior):

data\nbob (2 lines)

One solution here is to simply include the \n in the input rather than stripping it, making this case unambiguous, and I know some other languages take this path.

Thoughts?

[joshgoebel]

To me nil makes sense because it's seems perfectly natural (and a bit nicer) to use the reader directly in a loop:

while (data=Stdin.readLine()) {
  // process data
}

vs checking EOF then reading:

while (!Stdin.isClosed) {
  data = Stdin.readLine()
  // process data
}