Daniel Keep wrote:
Georg Wrede wrote:
Readln returns a string which contains the line terminator.
<snip>
Because if it stripped it, there's no way to know what it was. If you
want to do per-line processing but don't want to clobber the line
endings, readln has to return the line terminator.
But readln only stops on '\n' (or whatever character you tell it to
otherwise), so will miss Mac "\r" endings altogether. As such, it's
useless for this purpose.
The big question, however, is why std.stream.InputStream doesn't have
readln. It has readLine, which has different semantics - it understands
all three line break styles and strips them. This is absurd since
you're more likely to care about what line ending is used when reading
in a text file than when reading from stdin.
Take these four cases:
(a) you want to process only files with a specific line ending style
(b) you want to know what line endings are used
(c) you don't care about what line endings are used, but still want to
know whether or not the file ends with one
(d) you just want to read the file line by line, without caring about
the line endings or the presence or absence of one at the end
At the moment, readln is good only for (a). readLine is good only for
(d). If you want (b) or (c), you'll have to come up with an alternative
means.
Stewart.
