On Fri, Oct 18, 2013 at 06:26:05PM +0200, Max Samukha wrote: > On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu > wrote: > >On 10/18/13 3:44 AM, Regan Heath wrote: [...] > >>Take this simple design: > >> > >> string readline(); > >> > >>This function would like to be able to: > >> - return null for EOF > >> - return [] for a blank line > > > >That's bad API design, pure and simple. The function should e.g. > >return the string including the line terminator, and only return > >an empty (or null) string upon EOF. > > > > > >Andrei > > *That's* bad API design. readln should be symmetrical to writeln, > not write. And about preserving the exact representation of new > lines, readln/writeln shouldn't preserve that, pure and simple.
I agree. A better solution is to provide an eof() method (or better, .empty) that tells you when readln() will succeed, and readln() should throw upon EOF. The problem is analogous to reading from an input range: you always check whether the range is .empty before you call .front, since when the range is empty .front has no meaningful value to return. Relying on some kind of special sentinel value to represent the absence of a value is a code smell. T -- Тише едешь, дальше будешь.
