let example: (String, String, String) = ("ref".to_string(), "to".to_string(), "ref".to_string());
let example: (&str, &str, &str) = match &example {
(ref1, to, ref2) => (ref1, to, ref2),
};
Which might look confusing to people, it's converting from &(1,2) to (&1,&2)... but it's still type safe. Besides something like this, is there another reason to be worried about it?
Reading (or even writing!) rust code, you can get increasingly far without knowing what level of indirection you're operating on. I don't enjoy that. I don't personally feel like the notational burden for explicitness is enormous.
For field access/method calls, autoderef is a bigger convenience because we don't have the C++ -> operator, but I think I'd have preferred a syntax change here over the current behavior.
The match changes here don't bother me anywhere near as much as deref coercions do, because they preserve the level of indirection.
Deref coercion makes a &Box<T> behave like a &T (removing a level of indirection). Default binding modes only make a &(T, U) behave like a (&T, &U).
I've idly wondered whether it would have been possible to replace deref coercions with something like this. Making Box<T> behave like &T kinda works but loses you the ability to control `&T` vs `&mut T`, but maybe `x.y` where `x: &T` could "pass the reference on" giving you a `&U`.
Personally, not a fan of the match change. But then I was already not a fan of autoderef in method calls.