If you are reading text from a file, then the definition of "line" that is returned by this method is incomplete because it does not specify correctly what happens at the end of a file that is missing a CR,LF,CR/LF at the end of the file.
The definition of "line" as of 4/25/2008 reads thus:
A line is defined as a sequence of characters followed by a line feed ("\n"), a carriage return ("\r") or a carriage return immediately followed by a line feed ("\r\n"). The string that is returned does not contain the terminating carriage return or line feed. The returned value is nullNothingnullptra null reference (Nothing in Visual Basic) if the end of the input stream is reached.
Thus a "line" returned is defined by three cases:
1. Characters ending in LF
2. Characters ending in CR
3. Characters ending in CR/LF
I have observed that there is a fourth case, not included, where a "line" is actually returned. That is the case where there is a sequence of characters not followed by a LF, a CR, or a CR/LF, which are the FINAL CHARACTERS in a file. Thus the fourth case that should be included in the correct definition of "line" could read thus:
4. A sequence of characters that occur at the end of a file that is being read, which are not followed by LF, CR, or CR/LF.
Another way to make this definition correct would be to add the specification that a LF is "assumed" to occur at the end of every read file, whether or not the actual linefeed (e.g. encoding of an 8-bit ASCII byte with value 10) is really present or not as the last character of the file content.