Closed asomers closed 5 years ago
Hey @asomers, thanks so much for bringing this to my attention. I haven't had very much time to work on Simulacrum recently, but this strikes me as an important thing to be able to have work.
Thanks for taking an interest! BTW, it isn't just Simulacrum. There literally isn't a single mock library for Rust that whose mocks are Send
.
I was able to make ExpectationT
implement Send
(https://github.com/ramosbugs/simulacrum/commit/1be72ba2e0e0113e48756525f8342441670a6b49), but it would constitute a breaking change. I'm not sure how many users would be impacted by that. Thoughts?
I think it's not insignificant that you place a Send
bound on I
. That would prevent using Simulacrum to mock a function that takes an Rc<T>
argument, for example. The solution I came up with (but haven't published yet) is to use Fragile
for non-Send
types.
interesting! I think for my use case, Fragile
wouldn't work because I need another thread to actually read the return value of a mocked function, and from my understanding of Fragile
that would fail since it's not the original thread. But, I agree that requiring Send
is a big ask. I'll probably just restructure my code to mock out the thread creation to sidestep the issue.
Fixed in 6b3066a434f5c0e53252040cc11e1c73630a2875. Thank you @asomers for the suggestion to look into the fragile
crate!
Simulacrum's
ExpectationT
objects are notSend
, which means that Simulacrum cannot mock a trait that'sSend
. Example:This results in the error: