Calling take could wrongly pop an extra line from the range.
Solved by making ByLine use reference-counting.
Note: Just changing ByLine not to eagerly read the next line was not
sufficient to handle all cases properly (plus that makes empty() less
efficient).
Note: ByLine was documented until recently.
Add an overload of byLine without a default argument for terminator.
Before, byLine!string tried to instantiate "string terminator = '\n'",
which is invalid.
Note: This removes the default arguments from ByLine.this, but the
constructor was never documented anyway (unlike the range primitives).
Make byChunk, lockingTextWriter return opaque types (but keep those
types public for backward compatibility).
Add byChunk range example.
Also document that ByLine's primitives can throw StdioException.
Move byLine examples from ByLine to byLine.
Fix LinesReader typo.
Explain that lines will not persist when using a mutable type for Char.
Document parameters.
Purge phantom fp parameter.
Add missing parameters and throws info.
Fix File.readln(buf) example to use char[] buf for reuse, not string.
Fix swapped readln() and File.readln() examples.
Separate readln() and readln(buf) docs because the behaviour and
return types are different.
Fixes an issue where `readln!S` did not forward the type "S" in `stdin.readln()` => `stdin.readln!S()` (that was my mistake, sorry)
Fixes an issue where `File.readln!S` assumed S was an "immutable string type". This should work:
char[] buf;
buf = myFile.readln!(char[])();
While buf is not reused after each call, there should be nothing preventing the user for mutating if he so (explicitly) wishes.
Added/improved unittests a wee little bit.
strings were first decoded to wchars, each wchar was then separately
decoded to dchar, resulting in 2 dchars in the surrogate block instead
of 1 correct dchar.
added unit test to verify readln decoding of non-ASCII characters
byLine expects readln to return with an empty buffer on end-of-stream,
which readln does not do for wchar and dchar. Also, the readln variant
that takes a terminator range returns incorrect concatenations of
lines because of the same issue. Fixed by setting buffer.length=0 in
readln for this case. Unit test updated to detect this issue.
Now that std.process will support pipe creation, the name isPipe will
only cause confusion, as it will in fact be false for "normal" anonymous
pipes. It is only true for files opened by popen(), and its purpose is
simply to ensure they are closed with pclose().
Updated documentation for all the C-like member functions \
(and the File ctor) to specify exactly what gets thrown when.
(note: Exceptions in std.stdio are a mess and should be made
more consistent. Also, it seems some member functions that
should check if the file is opened do not, but I don't know
if that might be intentional (as the C functions should fail
anyway, resulting in a throw))
