On Tue, Mar 19, 2024 at 6:40 PM Nigel Tao <nigel...@golang.org> wrote: > > The ubiquitous io.Reader interface's Read method returns a (int, > error). Surprisingly (for programmers coming from other languages with > a built-in or idiomatic Result<T, E> type), it's possible for both > return values to be non-zero. There's (often overlooked??) commentary > in https://pkg.go.dev/io#Reader that says: > > > Callers should always process the n > 0 bytes returned before considering > > the error err. > > So that (again, especially for programmers used to saying result? or > "try result" or similar Result<T, E> aware mechanisms in other > languages), the following Go code is incorrect: > > n, err := r.Read(buffer, etc) > if err != nil { > return err > } > doStuffWith(buffer[:n]) > > --- > > Do any of the early Gophers remember the motivations for designing > Read's semantics in that way? At the libc or syscall level (and my > reading of FD.Read in internal/poll/fd_unix.go), I don't think > read(fd, etc) can return both non-zero. > > Is it just that, if you've got a buffer of some sort (including the > compress/* packages), it can be more efficient (1 Read call instead of > 2) to return (positiveN, io.EOF)?
Some earlier discussions: https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/jq8lAQhenaoJ https://groups.google.com/g/golang-nuts/c/WGYJx3ICCW4/m/1L0WcN8eqmkJ See in particular this message from Russ: https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/sbbgr9MUo9QJ Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV1_rBwW2BcrV-1UkOFepvBq96bF7xfJRHp8tMiOsDpVQ%40mail.gmail.com.
