Closed cherrywoods closed 4 years ago
This is a valid question. I decided to have both cases because MessagePack supports both single- and double-precision floating point values.
Sure, but it also supports a wide range of integer formats and there is only one case for each signed and unsigned integers, not one for each underlying integer representation as binary msgpack data.
In case of integers and unsigned integers, the pack method uses the smalles possible representation (as the specification suggest)
If an object can be represented in multiple possible output formats, serializers SHOULD use the format which represents the data in the smallest number of bytes.
When using float/double, the user has to decide which binary representation he/she wants to use, because pack never converts .double to .float, even if the double could be representated as a single precision floating point number.
I would at least want to have an initalizer that I can pass a Double and that returns me a .float, if my Double fits into one, so I don‘t have to figure that out myself. Actually I would want the default initalizer to behave this way.
To me, it looks like the framework is a bit inconsistent at this point, comparing integers and floating point numbers, but maybe there‘s a reason for this?
Why are there
.float
and.double
cases inMessagePackValue
? Why does this framework not convert to the smallest possible representation here as it does with integers and as the msgpack specification suggests?I just can't see a reason for this... To me it seems as if this could be implemented very easily using
Float(exactly:)
.