Add readLine and readLineSlice as methods to InStream

[jayschwa]

std.io.readLine and friends are top-level functions that read from the stdin stream or passed-in stream. InStream already has a wide variety of methods on it, and it seems inconsistent that readLine would be top-level functions, while all the other readFoo-style functions are methods on InStream.

If implemented, the top-level readLine functions could become wrappers for the new methods, and eventually be deprecated and removed.

One of the nice things that readLine does is DRY the getStdIn().inStream().stream ceremony. Proposal #3823 addresses that.

[ikskuh]

readLine ist just a special case of InStream.readUntilDelimiterAlloc or InStream.readUntilDelimiterBuffer

See:

zig/lib/std/io/in_stream.zig

Line 125 in 4b6740e

pub fn readUntilDelimiterAlloc(self: *Self, allocator: *mem.Allocator, delimiter: u8, max_size: usize) ![]u8 {

zig/lib/std/io/in_stream.zig

Line 103 in 4b6740e

pub fn readUntilDelimiterBuffer(self: *Self, buffer: *Buffer, delimiter: u8, max_size: usize) !void {

I think it's better this way as with a readLine-Function, the zig std will assume a defined "newline sequence" which may not be the same on all environments

[jayschwa]

readLine ist just a special case of InStream.readUntilDelimiterAlloc or InStream.readUntilDelimiterBuffer

Agreed, but why does it make sense for readLine to be standalone and for readUntilDelimeter to be a method? readUntilDelimeter and many other readFoo-style methods could just as easily be standalone functions like readLine, but they aren't, so what is the distinction?

the zig std will assume a defined "newline sequence" which may not be the same on all environments

I don't follow. How is the assumed newline sequence a point in favor of standalone function versus method?

[andrewrk]

I see why this was problematic now, but std.io.readLine is named after GNU readline and is intended for the use case of an interactive command line, rather than streams. (There is a lot more work that would need to go into this API before it is fully functional, so it's understandably confused with a simple stream line reader)

[daurnimator]

FWIW this will all get much cleaner if the stream mixin concept is integrated. Currently discussion of Mixins is going on in #3785

[jayschwa]

I am closing this issue because it is no longer relevant. Standalone std.io.readLine no longer exists.

[andrewrk]

fwiw I think this is going to be satisfactorily solved in this branch

[jayschwa]

Yeah, I kind of figured with the upcoming redesign. It makes sense that BufferedReader should have all the convenience functions and Reader should simply "fill this buffer". Having the convenience functions on Reader made it easy to do the wrong thing w.r.t. excessive syscalls.