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
Some custom types rely on Serde annotations to specify custom (de)serializers. An example of this are the types from the time crate, where we use Serde's with annotation to specify they should be (de)serialized using RFC339 formatting.
Unfortunately, those annotations can only be used in field positions, such as struct and enum variant fields. This means this approach breaks down when passing the types directly as function arguments, for instance.
However, because our bindings inject wrapper functions anyway, we could theoretically make those wrappers aware of the annotations and call the correct (de)serializer when such an annotation is used on a type that is passed as an argument or returned as a value. This would shield our users from one more edge case, though the edge case of using such types as a generic argument remains.
For the time being, we recognize this issue exists and advise users to use newtypes to work around the issue. A warning is displayed when a user's protocol may run into these issues, as implemented in #110.
The text was updated successfully, but these errors were encountered:
Some custom types rely on Serde annotations to specify custom (de)serializers. An example of this are the types from the
time
crate, where we use Serde'swith
annotation to specify they should be (de)serialized using RFC339 formatting.Unfortunately, those annotations can only be used in field positions, such as struct and enum variant fields. This means this approach breaks down when passing the types directly as function arguments, for instance.
However, because our bindings inject wrapper functions anyway, we could theoretically make those wrappers aware of the annotations and call the correct (de)serializer when such an annotation is used on a type that is passed as an argument or returned as a value. This would shield our users from one more edge case, though the edge case of using such types as a generic argument remains.
For the time being, we recognize this issue exists and advise users to use newtypes to work around the issue. A warning is displayed when a user's protocol may run into these issues, as implemented in #110.
The text was updated successfully, but these errors were encountered: