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
With the currently available documentation it is unclear how a composite type (say, point = [x: int, y: int] / struct Point(x, y) would be decoded. The closest trait to implement is CBORDecodable, but that requires a &mut Point as input, which needs to contain a valid representation before parsing. This may work well for complex types where all components are optional (so that before decoding a default empty instance is created), but needs workarounds like allowing some actually-uninitialized state, and extra safeguards to ensure that that doesn't go wrong.
My impression of CBORDecodable is that it conflates two concerns:
It ensures that the struct doesn't get passed around, but is pre-allocated in its eventual position. (I don't know how well the Rust compiler handles return placement in general, but it seems to do well in simple cases.)
It simplifies handling of types with many default properties.
I could come up with various suggestions, but think that best progress would be made here if the rationale behind the current API (and possibly examples) were documented. How should a type like the above Point be used with CBORDecodable?
The text was updated successfully, but these errors were encountered:
With the currently available documentation it is unclear how a composite type (say,
point = [x: int, y: int]
/struct Point(x, y)
would be decoded. The closest trait to implement is CBORDecodable, but that requires a&mut Point
as input, which needs to contain a valid representation before parsing. This may work well for complex types where all components are optional (so that before decoding a default empty instance is created), but needs workarounds like allowing some actually-uninitialized state, and extra safeguards to ensure that that doesn't go wrong.My impression of CBORDecodable is that it conflates two concerns:
It ensures that the struct doesn't get passed around, but is pre-allocated in its eventual position. (I don't know how well the Rust compiler handles return placement in general, but it seems to do well in simple cases.)
It simplifies handling of types with many default properties.
I could come up with various suggestions, but think that best progress would be made here if the rationale behind the current API (and possibly examples) were documented. How should a type like the above Point be used with CBORDecodable?
The text was updated successfully, but these errors were encountered: