Open epoberezkin opened 5 months ago
Interesting. I haven't thought about that yet, I'll think about it. Do you have suggestions?
There are two options here: either add config to type class, like Aeson does, or add it to decode function.
Given that type classes are unlikely to re-define basic objects and map encodings, the latter is probably better - we could add a version of decoding function that accepts options.
Since decode always goes through the data type (unlike aeson, which can do direct decoding from byte arrays without going through the object model), maybe we can have a profile validation operating on the object model?
The spec defines the encoding profiles, e.g. prohibit binary (we don't need it, binary support is our main motivation to consider moving to MessagePack), or restrict key types to strings (this is actually something we need).
Any view on how it could be added?