reader.takeDelimiterExclusive('\n') behaves incorrectly

[xingyuli]

Zig Version

0.15.2

Steps to Reproduce and Observed Behavior

Run this Zig program, it failed to read the file as it is previously in 0.15.1.

With file content intest_data:

123456
abcd
rer

And program in read_file.zig:

const std = @import("std");

pub fn main() !void {
    const f = try std.fs.cwd().openFile("test_data", .{});
    defer f.close();

    var buf: [1024]u8 = undefined;
    var file_reader = f.reader(&buf);

    const reader = &file_reader.interface;

    while (reader.takeDelimiterExclusive('\n')) |line| {
        std.log.debug("1: '{s}'", .{line});

        if (line.len == 0) {
            // std.log.debug("2: '{s}'", .{reader.buffered()});
            break;
        }
    } else |err| switch (err) {
        error.EndOfStream => {
            std.log.debug("eof", .{});
        },
        error.StreamTooLong, error.ReadFailed => return err,
    }
}

It simply produces wrong output:

$ rm -rf .zig-cache zig-out && zig version && zig run read_file.zig
0.15.2
debug: 1: '123456'
debug: 1: ''

Expected Behavior

$ rm -rf .zig-cache zig-out && zig version && zig run read_file.zig
0.15.1
debug: 1: '123456'
debug: 1: 'abcd'
debug: 1: 'rer'
debug: eof

[mlugg]

It was a mistake that this behavior change was included in the 0.15.2 release (since the patch release should have been non-breaking).

However, this is the intended behavior: see the doc comments on the takeDelimiter* functions for details. In general, if you were previously using takeDelimiterExclusive, you now want takeDelimiter instead. It's similar to the old takeDelimiterExclusive, but it returns null instead of error.EndOfStream, which is a more convenient API in the common case; for instance, your usage would now look like this:

// using 'try' here
while (try reader.takeDelimiter('\n')) |line| {
    // (loop body here)
}
// no need to `switch` on the error

While it was a mistake to include this change in 0.15.2, we are not going to release a 0.15.3 which reverts it; that would just cause more code churn in practice. Apologies for the error, though.

[daurnimator]

However, this is the intended behavior: see the doc comments on the takeDelimiter* functions for details. In general, if you were previously using takeDelimiterExclusive, you now want takeDelimiter instead. It's similar to the old takeDelimiterExclusive, but it returns null instead of error.EndOfStream, which is a more convenient API in the common case; for instance, your usage would now look like this:

// using 'try' here
while (try reader.takeDelimiter('\n')) |line| {
// (loop body here)
}
// no need to switch on the error

I'm not sure that is correct?
You want takeDelimiterExclusive for the common case where you want to support no new lines at the end of the file.
So for the most common case, you now need:

while (reader.takeDelimiterExclusive('\n')) |line| {
    // (loop body here)
    reader.toss(1);
} catch (err) switch (err) {
   EndOfStream => {},
   // other error handling
}

[xingyuli]

0.15.2's behavior of takeDelimiterExclusive is weird. Users can only get updated usage example via the official release changes (about 0.15.1) that telling:

But this simply broken, if you try this example or use the code given in my reported issue, I would go mad @mlugg

If no changes would be taken, I have only once choice to stick my build with 0.15.1, avoid using the weird 0.15.2 .

And, let's what it would be like in the next release changes.