Hi,

I've just found out about BARE and would like to offer 
some of my observations as I've seen that feedback is 
(still?) welcome as the specs aren't yet finalized.

Regarding variable-length integer encoding in BARE, 
there's an alternative to (U)LEB128 encoding that is 
simpler and faster. Little-endian prefix VarInt encodes 
64bits in 1–9 bytes and can be implemented without a loop.

Here's an example implementation (not made by me)

     - https://docs.rs/vint64/latest/vint64/
     - 
https://github.com/iqlusioninc/veriform/tree/develop/rust/vint64


Another thing regarding varints is that often a signed 
integer type is used to store only positive values. 
Which makes it storing as zigzag encoded sint less 
efficient. Protobuf has three types of varints for that 
purpose (int, sint, uint), where int is not zigzag 
encoded. To make it more clear, it could be named 
something like `pint` (positive int). So the three 
varint types could be:

     - pint (positive signed int, encodes negative 
numbers as two’s complement)
     - sint (signed int, uses zigzag encoding)
     - uint (unsigned int)

These are just some of my observations. I understand 
they might not be good fit for BARE's vision which is 
fine. I just thought to offer some food for thought.

Best, zig

Hello zig, thank you for your feedback.

> Regarding variable-length integer encoding in BARE, there's an
> alternative to (U)LEB128 encoding that is simpler and faster.

Variable-length integer encoding was discussed in the following threads:
- https://lists.sr.ht/~sircmpwn/public-inbox/%3C1dfb75c3-86a3-276a-ca9a-ba9da0df376d%40elvinger.fr%3E
- https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAFFTG-a-Vci%2BkS_d_%3DuaX8kyxszqtB-79pcb5580Z9xw72V5kw%40mail.gmail.com%3E

Please, note that changing the encoding would break current
implementations, which is strong argument against.

> Another thing regarding varints is that often a signed integer type is
> used to store only positive values. Which makes it storing as zigzag
> encoded sint less efficient.

I am sorry but I probably misunderstand. Why would be positive integers
stored as int when there is uint?

Hello Jiri, thank you for your replay.

> Please, note that changing the encoding would break 
> current
> implementations, which is strong argument against.

I agree that breaking current implementations only 
because of this wouldn't be reasonable, as it's just a 
minor improvement.
It would only make sense to consider this in the event 
of a new specification with breaking changes. If that 
ever happens.

> I am sorry but I probably misunderstand. Why would be 
> positive integers
> stored as int when there is uint?

Just to avoid casting in user code from ints to uints 
and back to ints when interacting with BARE-generated 
objects.
I don't have real statistics, but I would say that 
positive integers stored as ints are probably extremely 
common, especially
if value range of the positive integer is small. This 
too would be only a minor improvement.