[cbor] Unable to use numbers as map keys

[dignifiedquire]

I am trying to marshal a type map[uint64]*somestruct, but cannot do so, as I get the error messags unsupported map key type "uint64". This is really unfortunate, because one of the great things about cbor is that I can use numbers as keys in maps.

Code that throws the error: https://github.com/polydawn/refmt/blob/master/obj/marshalMapWildcard.go#L24-L55

[warpfork]

You've already seen it, but I'll reproduce the comment in there here for posterity/context:

// note: stdlib json.marshal supports all the int types here as well, and will
// tostring them. but this is not supported symmetrically; so we simply... don't.

This is a feature I had some questions about implementing because if you use it, you're giving up on the ability to drop in a json encoding, and I think it's worrying to do that without making it clear. And in particular, I still don't approve of an implementation that silently coerces ints to strings in a lossy one-way trip.

I think I'm onboard with expanding this, though. The right way to do it is to have the obj/* code understand numeric map keys just fine (like they do, say, byte slices), and have the json/* code reject that, and the cbor/* code also accept it. These comments about json problems being in the obj package are... Yeah, old and stale and misplaced and should be fixed.

[warpfork]

I think this should be pretty easy to fix to handle numerics, and I can try to get to it sometime next week.

[warpfork]

Out of curiosity, are you using the entire range of uint64? That seems like some interesting code, if so.

I'm brought to wonder because I looked at implementing numeric keys yesterday, and balked because the deterministic ordering sort code as currently written and modified in the most obvious way would get pretty ugly -- especially since it would require both uint64, and int64, all of them -- to work correctly for inputs in the highest half of uint64 -- and probably ought to have int/uint paths for that common case to save casting time as well.

I'm pondering whether it's going to turn out better to implement a whole specialized marshalMachine for each numeric type. But that's not without its drawbacks either. Kind of hoping for a better implementation idea to strike me than the ones I've got so far.

[dignifiedquire]

yeah, I will nedd to be able to rely on the fact that any uint I put in works.

…

On 6. Oct 2018, 12:15 +0200, Eric Myhre ***@***.***>, wrote: Out of curiosity, are you using the entire range of uint64? That seems like some interesting code, if so. I'm brought to wonder because I looked at implementing numeric keys yesterday, and balked because the deterministic ordering sort code as currently written and modified in the most obvious way would get pretty ugly -- especially since it would require both uint64, and int64, all of them -- to work correctly for inputs in the highest half of uint64 -- and probably ought to have int/uint paths for that common case to save casting time as well. I'm pondering whether it's going to turn out better to implement a whole specialized marshalMachine for each numeric type. But that's not without its drawbacks either. Kind of hoping for a better implementation idea to strike me than the ones I've got so far. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[whyrusleeping]

@warpfork I need this bad.