+1
I’d love to hear more about the motivation behind the io.EOF as an error. And why select a strategy to prefer *no* *discriminated unions* for the error results? Why transport non-error information in error values (io.EOF, 'http.ErrServerClosed)? “Normal” vs. “error” [control flow] is a fundamental semantic distinction, and probably the most important distinction in any programming language - Herb Shutter The io.Reader has caused many problems during its existence. Even so, the os packages official documentation <https://pkg.go.dev/os> and the File.Read example starts with a potential bug and incorrect io.Reader usage. Should the if clause be: if err != nil && err != io.EOF { ... The issue #21852 <https://github.com/golang/go/issues/21852> gives an excellent overall picture of how deep unintuitive io.EOF usage can affect Go’s code and test base. It includes an interesting comment that maybe Go 2 will fix the io.Reader. Now it’s official that there will never be Go 2, maybe io.Reader2? On Wednesday, March 20, 2024 at 6:39:29 AM UTC+2 Nigel Tao wrote: > On Wed, Mar 20, 2024 at 2:13 PM Ian Lance Taylor <ia...@golang.org> wrote: > > 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 > > Russ said: > > > Once in a while we think about changing the definition > > to require n==0 when err==EOF but it doesn't help the > > more general case, a partial read that returns an error > > saying why more data wasn't returned (disk error, etc). > > OK, partial reads are a thing, but one possible design (in hindsight, > not now) was to push the complexity in tracking that into Read > callees, not Read callers. Instead of a callee returning (positiveN, > nonNilErr), have it save nonNilErr to a struct field and return (0, > nonNilErr) on the next Read call. > > I'd expect fewer programmers writing callees than callers, and they'd > generally be more experienced Go programmers. Anecdotally, when I was > doing a lot of Go code reviews some years ago, I'd often have to point > out the "Callers should always process the n > 0 bytes returned before > considering the error err" comment, often to the programmer's > surprise. > > While it's relatively easy, *if you already know*, to do this: > > n, err := r.Read(buffer) > doStuffWith(buffer[:n]) > if err != nil { > return err > } > > instead of this: > > n, err := r.Read(buffer) > if err != nil { > return err > } > doStuffWith(buffer[:n]) > > it's not really obvious if you don't know that you don't know. And > sometimes doStuffWith is more than just "something += n". If > doStuffWith can itself lead to further errors (e.g. you're parsing the > bytes you've just read), you also have to be careful not to clobber > the err variable. > > Anyway, it's far too late to change it. I was just wondering if there > was some motivating reason that I'd otherwise missed. > -- 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/3f26b58e-b451-4fdd-b0b8-17638a30ce4en%40googlegroups.com.
