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
In a lot of places we accept an id (like AccountId) by value, requiring spelling out .clone() in a lot of places where the id cannot actually be consumed.
A very similar problem is faced when passing strings in rust. Into<String> is a generally acceptable way to receive an owned string value, while allowing implicit clones of &String and &str.
I think we can get a similar benefits by implementing From<&Id> for Id for all out id types and using Into<Id> in function signatures. Then instead of whiff(floof.clone()) we would be able to write whiff(&floof).
I feel the client-facing APIs (like constructing instructions and queries) could benefit greatly from this: our integration tests have a lot of clutter in form of .clone()s. Some parts of iroha_core might benefit too.
The text was updated successfully, but these errors were encountered:
In a lot of places we accept an id (like
AccountId
) by value, requiring spelling out.clone()
in a lot of places where the id cannot actually be consumed.A very similar problem is faced when passing strings in rust.
Into<String>
is a generally acceptable way to receive an owned string value, while allowing implicit clones of&String
and&str
.I think we can get a similar benefits by implementing
From<&Id>
forId
for all out id types and usingInto<Id>
in function signatures. Then instead ofwhiff(floof.clone())
we would be able to writewhiff(&floof)
.I feel the client-facing APIs (like constructing instructions and queries) could benefit greatly from this: our integration tests have a lot of clutter in form of
.clone()
s. Some parts ofiroha_core
might benefit too.The text was updated successfully, but these errors were encountered: