Wait.. you're saying Mutex<&T>, not Mutex<T>. The type Mutex<&T> shouldn't be requiring T: Send at all already – just T: Sync – but the T: Sync bound is required for both Mutex<&T>: Send as well as Mutex<&T>: Sync.
Thank you for your reference. But the conclusion seems to be the opposite: Mutex<&T> is UnsaveCell<&T> in disguise, and UnsaveCell<&T> is &&T in disguise. So, accordingly to the document you linked to, Mutex<&T> should be Send indeed, so I seem to be correct.
You are right, I have an error: &T may be "equal" to some mutable reference and it breaks sychronization.
So, to make my code work, we need to ensure that the passed &T is the only reference to our object (of type T) or at least there are no &mut references to it. The only way I know to do this, is to wrap &T inside an unsafe Sync struct with &T as a private field. This unsafe Sync struct cannot be implemented in a "general" way, because generally &T can be return value of a function and nothing prevent a function to make also &mut references. Therefore the unsafe Send struct needs to be implemented every time anew. Too bad.
If there is no any other way, the following new Rust feature would be useful: Make &T: Sendwhile there are no known mutable references. Adding this feature would solve my Mutex troubles automatically.
(Sorry for polluting this group with a relatively novice's ideas, but not to respond to your message is also not good.)
No problem, I was mostly concerned about future topics, not knowing at what rate you were planning to post further ideas that are mostly questions for help in disguise (help with understanding technical details); when it's already open, we may as well keep using this thread. Also on users.rust-lang.org there tend to be more people willing to answer (novice) questions so you might get answers faster and/or better answers.
Feel free to still open topics for ideas on internals.rust-lang.org whenever you do think understand the details a bit better, or e. g. if other Rust users on users.rust-lang.org already confirmed the idea could make sense.
Tip: while you are a newcomer to Rust, it's safer to assume that the authors of the standard library know its internal workings better than you do, and that functionality is not "missing", it is rather left out intentionally.
Unsafe code is specifically hard to reason about unless you are really experienced. Unless you have at least an informal proof of the soundness of your proposal, you should just probably not post it at all. I.e., if you need to ask if it is sound, it usually isn't. (The same goes for compiler bugs.)