Please answer these questions before submitting your issue. Thanks!
I want to use binary.Read() to marshall data to/from network byte-order.
I must keep track of my offset from the beginning of the stream (I'm decoding DNS records, which sometimes refer to strings found at offsets-from-0 farther back as a form of compression).
I would prefer not to require the use of an io.ReadSeeker just for the sake of discovering my current offset.
I expected binary.Read() to return the number of bytes read, as all of the io.Read implementations do.
It doesn't! This seems like a silly oversight, but also not a big or difficult change.
I created a trivial library to replace the function. In retrospect, it would be better to have a differently-named function in the upstream Golang binary package so that Go-1.x compatibility isn't broken. binary.Read could be a wrapper which just drops the bytesRead return value.
Whether or not the API is a mistake, it's frozen now, as you've noted.
The other possibility is you can pass in an io.Reader wrapper that counts how many bytes have been read through it.
It doesn't seem worth adding more API to the package at this point.
@bradfitz somehow that possibility hadn't occurred to me, guess I'm still getting used to satisfying interfaces.
The workaround will definitely suffice but I still hate the inconsistency. Is there a Wish List of things the Go team would like to get more right in a Go-2.0, if such a thing ever comes to be?
Thanks for the swift response!
The wishlist is issues with the "go2" label.
@ianlancetaylor can we add that label here, rather than closing it as a "let's never fix that"?