It's that time again, lads In all seriousness, though? This combo felt *really* intimidating and verbose before, and now I'm just like whatever, it's neat I guess?pic.twitter.com/oxno3FSvWL
Show this thread
-
Right, but why would you use a "this thing does locking" constraint if you didn't need to do locking? And yeah, Arc is perhaps already represented as some combination of existing traits.
What I'm saying is that if the type that represents "this type does locking" isn't something separate like Mutex or RwLock, everybody is paying that cost whether they need it or not. E.g. in the code example in the OP, if OroClient satisfied this, it'd impose that cost on all
-
-
OroClient wouldn't have to satisfy this. Arc<Mutex<OroClient>> already satisfies this. But the trait would mean the caller gets to decide which locking mechanism is used, rather than the author of the function. So they could pick RwLock instead of Mutex, for example.
-
In other words, a function with a trait bound on Send + Sync + Lockable (say) could be given either an Arc<Mutex<T>> or an RwLock<T>.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.