Doubles: reasons for disallowing exponential form

[mgravell]

The specification indicates, for doubles:

Exponential format is invalid.

However, this means that very large and very small values are now very verbose on the wire; additionally, many frameworks make not using E format challenging. This is also contrary to previous redis handling, which allows E formats, for example in the INCRBYFLOAT documentation there exists the sample:

INCRBYFLOAT mykey 2.0e2

For example, IEEE754's max/min values would be over 300 bytes, to transmit a theoretically 8 byte payload.

I'd like to challenge whether this is a good idea, preferring to allow exponential form when appropriate. It is also notable that some platforms make it actively hard to not use E form.

[kristoff-it]

It is also notable that some platforms make it actively hard to not use E form.

RESP3 only changes how replies are generated by the server, which is somewhat orthogonal to how commands work as all arguments are ultimately sent as strings to them.
If your client library is able to handle a superset of what the server will send you, you're still fine.

Your points about space savings are still perfectly valid though.

[mgravell]

@kristoff-it I reject that statement due to the premise of RESP3 not being simply redis:

however the protocol is designed to be used by other projects

(from the home page)

So: the format needs to be considered in the general case, not simply with the added caveat that one particular usage never uses a particular message type in a particular direction.