On Wed, Mar 20, 2024 at 2:13 PM Ian Lance Taylor <i...@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/CAOeFMNWpRyz21T%2BLDjjdb5kFJ3XeEx3kCeB4MkqzOPVNHfTK6w%40mail.gmail.com.
