Russ Cox

Why are the types uncommon (for Go APIs) sizes like uint32? Can they all be int? Otherwise this seems fine.

It seems like now that this has outgrown being an HTTP/2 guts package, we should probably use Go types (int or else int64 if it really matters) instead of wire...

Have all remaining concerns about this proposal been addressed? The proposal is https://github.com/golang/go/issues/67813#issue-2333927077, except using ints instead of uint32 etc.

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group The proposal is https://github.com/golang/go/issues/67813#issue-2333927077, except using ints instead of uint32 etc.

No change in consensus, so **[accepted](https://go.dev/s/proposal-status#accepted)**. 🎉 This issue now tracks the work of implementing the proposal. — rsc for the proposal review group The proposal is https://github.com/golang/go/issues/67813#issue-2333927077, except using...

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

Have all remaining concerns about this proposal been addressed? The proposal is to document that crypto/rand.Read and crypto/rand.Reader.Read always return the full amount requested and never return errors. If the...

Plan 9 does not have /dev/urandom. It has /dev/random. That may not be present in the name space. But '#c/random' is always present, and the code should be opening that...

@FiloSottile and I discussed this. We believe that func Read should be documented to never return an error. It is also documented to use Reader, but if it observes an...

Have all remaining concerns about this proposal been addressed? The proposal is to document that rand.Read never returns an error, nor does the default rand.Reader. If rand.Reader is set to...