Similar to io.Reader, the bitio.Reader should return the partial value when it encounters an error.

---

This change is 

Codecov Report

Merging #1 into master will not change coverage. The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #1   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           2      2           
  Lines         153    153           
=====================================
  Hits          153    153

Impacted Files	Coverage Δ
reader.go	100% <100%> (ø)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 261d100...84960af. Read the comment docs.

While this is a good idea in general, without knowing how many useful bits the result still contains despite the io.EOF, it's not really useful.

E.g. if the result is 0x01, io.EOF. How many bits would you use? 1? The result surely has at least 1 useful bit as that is 1, but you don't know if there are 2, 3, or more. You can't distinguish between bits being 0 because they were 0 in the input, and bits being 0 because there were no more bits in the input.

The case with io.Reader.Read() is different, as that returns the successfully read bytes, so you know how many bytes you can use from the results.

The current behavior encourages conscious use of the bit reader: you have to know how many bits you're expecting. In some situations this may require you to encode this info into the stream. But at least you always know what to expect.

For this reason, I tend not to include this modification as-is. What do you think?

That's reasonable. I'll have to track the number of bits read in my read loop. I think the best solution is for ReadBits to return the number of bits read as well.

This could be done (returning the number of read bits). But I would prefer to add a new method to keep backward compatibility, e.g.

ReadBitsWithCount(n byte) (u uint64, count byte, err error)

Also if we're adding ReadBitsWithCount() it would be reasonable to also add the follwoing analogue methods: ReadWithCount(), ReadByteWithCount() (which also return the exact number of bits read).

And if we're at it, similar methods could also be added to bitio.Writer which report the exact number of written bits.

Do you think this is reasonable / needed? The API is minimal and clean right now. This would almost double the API methods. Of course we can opt to only add ReadBitsWithCount() and WriteBitsWithCount() as a middle-way.

I think the additional methods makes the API less enjoyable.

Considering this package is fairly small and most Go users are vendoring I think the API breakage is preferable. The fix for affected users is easy too: just adding a , _. Maybe the best course of action is waiting for dep to be merged.

Hi,

Just trying to weigh in a bit.

Considering this package is fairly small and most Go users are vendoring

I use this library heavily. And I dont use vendoring. Just waiting for dep to stablise.