[bluejekyll]

The biggest negative I've seen is this:

    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?

https://play.rust-lang.org/?gist=e37f9b31cc5e5c7b9d19c6b0a4c...

[ben0x539]

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.

[Rusky]

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`.