Replies: 2 comments 1 reply
-
|
On the same methods, it would be nice if the method "respected" the type from dynamo and returned the proper representation. For example, If we take the "principle of least surprise", I'd expect Consumers of the API should not need to parse and transform data types read from dynamo if those types are well known. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
This is fixed in #527 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently,
as_xyzaccessors returnOption<T>. But this can be confusing for users when the type is actually a different type. Instead,as_xyzshould returnResult<&T, &Self>:Proposal:
This should make the problem immediately clear and easy to debug.
Beta Was this translation helpful? Give feedback.
All reactions