[cbor] Unable to use numbers as map keys about refmt HOT 5 OPEN

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.

from refmt.

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

from refmt.

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.

from refmt.

from refmt.

@warpfork I need this bad.

from refmt.