feature: Add support for encoding Go float64 and float32 to shortest form of CBOR integer (dCBOR)

[bumblefudge]

Is your feature request related to a problem? Please describe.
In section 2.3 of the dCBOR application profile that the CBOR WG has been iterating the last 2 years, there is a more extreme numeric reduction of floats, not just from float32 > float16, but from either to int anywhere that an int is semantically identical.

Describe the solution you'd like
Would it be possible to refactor ShortestFloatMode to have int as one of the options, or is this a huge lift?

Describe alternatives you've considered
Alternately, in my use-case, the approach in #623 might work, defining some kind of FloatOrInt in the JSON<>CBOR rules for Floats that might get Int'd in dCBOR...

[fxamacker]

@bumblefudge Thanks for opening this issue! I was also following the progress of dCBOR, etc.

Converting floats to integers isn't difficult but it creates new scenarios that require more effort for the encoder to handle properly. For example, handling duplicate map keys created by numeric conversion from float to integer during encoding.

Some pitfalls when encoding a Go map using dCBOR draft-12 include:

• As mentioned in dCBOR, converting a float to an integer can convert unique map keys into duplicate map keys. Go map enforces unique keys so this is a new problem created by dCBOR which requires duplicate key detection during encoding.

• Go's iteration of built-in map is non-deterministic (intentionally randomized by Go), so dCBOR-based specifications requiring a keep-first or keep-last strategy to emit maps without duplicate keys can be problematic. Not emitting entire map would be more feasible in Go.

Given this, the encoder would not emit the map at all to dCBOR (if any duplicate keys are detected during numeric conversion) rather than attempting to deterministically remove duplicates from the map in order to emit it as dCBOR. Would that be acceptable?

Since dCBOR is still in draft status, implementing dCBOR support now risks having to make breaking changes later. I will keep an eye on it.

Please feel free to share any thoughts or info about your use cases for dCBOR (e.g. any dCBOR-based protocols or formats).

[bumblefudge]

yeah, i think unless/until dCBOR specifies what to do in that case, dropping the whole map (or failing outright) makes the most sense. thanks for pointing out that (understandably deal breaking!) case!