You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we wait for nim-lang/RFCs#548 to materialize, we can provide something ahead of nim compiler.
And because the usage is domain specific, we don't need full features to handle union like the compiler.
The idea is to create a special types recognized by the library along with a set of api to handle union.
The approach can be similar to nim-ssz-serialization's union, or similar to nim-json-serialization flavor.
Whatever we choose, the end product is little intervention from user and it should similar to what the compiler offers.
When the compiler ship the new feature, migration or combined usage is easy.
Important feature of this ability is to warn or error if the user combine ambiguous types e.g.
json_union(UnionType):
uint64int64
Because both int64 and uint64 will parse from the same json number, such union is invalid for json-serialization although it is valid for nim. The same apply to objects, if the list of sorted name of the fields is the same, they are invalid union.
The hardest part maybe the pattern matching to map literal json to the target type. The order of fields can be different to the target type, but if it's a valid json, it should still map to target type.
The text was updated successfully, but these errors were encountered:
Requests in nim-json-rpc:
I will call it a
union
.While we wait for nim-lang/RFCs#548 to materialize, we can provide something ahead of nim compiler.
And because the usage is domain specific, we don't need full features to handle union like the compiler.
The idea is to create a special types recognized by the library along with a set of api to handle union.
The approach can be similar to nim-ssz-serialization's union, or similar to nim-json-serialization flavor.
Whatever we choose, the end product is little intervention from user and it should similar to what the compiler offers.
When the compiler ship the new feature, migration or combined usage is easy.
Important feature of this ability is to warn or error if the user combine ambiguous types e.g.
Because both int64 and uint64 will parse from the same json number, such union is invalid for json-serialization although it is valid for nim. The same apply to objects, if the list of sorted name of the fields is the same, they are invalid union.
The hardest part maybe the pattern matching to map literal json to the target type. The order of fields can be different to the target type, but if it's a valid json, it should still map to target type.
The text was updated successfully, but these errors were encountered: