AppendVarint32(buf, x) is identical to AppendVarint(buf, int64(x)) (where x is an int32). Similar for the other functions, I believe. I'm not sure we need separate functions.

ReadUvarint provides bounds checking based on the MaxVarintLen64. Does the alternative offered provide this checking ability?

@randall77 Thanks for the feedback. I've removed the AppendUvarint and PutUvarint functions from the proposal as the bounds checking only applies to the Uvarint and ReadUvarint functions.

@alzeih That's a fair point for the reading variants.

We've gotten through over ten years without the lack of these being a problem. If there's a performance issue with AppendVarint(buf, int64(x)) for int32-valued x, maybe we can look at the implementation. But it doesn't seem like we need APIs for smaller ints, which are becoming less and less common.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

As previously discussed, this proposal is concerned with reading varints, not writing them.

What about a func that allows for a caller specified maximum number of bytes to read? This would work for legacy (16, 32-bit), non-standard (24-bit?), and future (128-bit) varint sizes. The existing constants could be provided as an argument.

What is the actual use case here?

Can you just read a varint and then verify that it is in range?

Reading a uvarint32 from a binary file format and not wanting the func to take more than it should out of the buffer, which would affect reading the rest of the file.

The varint encoding is self-delimiting. The limit of MaxVarintLen64 is to catch erroneous data. For correct data it will never be used. For erroneous data, it doesn't matter whether it affects reading the rest of the file, because the data is erroneous anyhow.

Okay. I was under the impression that reading more of the buffer than intended could be a bad thing (#41185). I can see this proposal is unlikely to proceed based on the feedback. Thanks for the input.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group