-
-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create custom async Clone trait #1850
Comments
I currently have an Example: |
@antoinevg Ok, so it looks like this switch is mandatory for your no-std work? What do you think if return type is ockam_core::Result ? |
|
The name may be AsyncTryClone |
Hi @SanjoDeundiak, is this issue taken up by someone else? If not, I would love to work on this. |
I'm not Sanjo, but I'm pretty sure nobody's started on it. |
Great! So, can someone assign this issue to me? Or, will this comment be sufficient? |
Hey @whereistejas , how it's going with the implementation? |
Hi @SanjoDeundiak, I'm currently reading through @antoinevg's Would I be correct in assuming that we need something similar, but it should also return |
It probably shouldn't panic if at all avoidable, ideally, it should return a The rough idea of a possible implementation might be: #[async_trait]
pub trait AsyncTryClone {
async fn async_try_clone(&self) -> ockam_core::Result<Self>;
} I think for now we should punt on whether or not to do anything fancier with it, like supporting other error types, adding a blanket impl for If you don't know where to use it or what to implement it for, it might be enough to submit the PR defining it as a first step (and that might be enough on its own). I'm not sure if @SanjoDeundiak had concrete plans there (I imagine there are a few, although I'm unsure where), but I also think that several of the places where it's useful might only exist in @antoinevg's branch (although I could be mistaken). That said, if you've already found places it would be useful as-is (from looking at @antoinevg's branch for example), I think you can feel free to implement those with the PR. |
Tnx @thomcc. This looks like perfect trait declaration at the moment. @whereistejas we want to land nonblocking branch soon, could you please submit PR, so we could start using this trait? If you also want, there are existing places in develop branch, where you can already integrate new trait (Just search for Clone impls, you'll find few with blocking and unwraps inside) |
@SanjoDeundiak sure! I will try to finish it by tomorrow and submit a PR. @thomcc thanks for the detailed comment, I think you have done most of the work, already! |
This was fixed with #1918 |
Standard Clone trait is a little ambiguous in sense that one usually expects to have a clone of existing object, while this is not true for our Handle-based and Handle-like structs (e.g. Entity, TcpRouterHandle, VaultSync), even though we implement Clone for them. During Clone these structs create new object which allows you to interact with some shared resource, that is not cloned. Standard library also does things like that, e.g. Arc. In addition to that, our Clone is usually async and may potentially return an Error, these 2 properties are not supported by std::clone::Clone. Having our own Clone trait could solve those problems, we also may implement std::clone::Clone for structs implementing our Clone, that implementation may block and wait for async function to finish, and panic in case error was returned.
The text was updated successfully, but these errors were encountered: