12 ms·

Hooray, congrats to the rust contributors, once again. :) Personally, not a fan of the match change. But then I was already not a fan of autoderef in method ca

• bluejekyll 8y ago
  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=e37f9b31cc5e5c7b9d19c6b0a4c44441&version=stable&mode=debug https://play.rust-lang.org/?gist=e37f9b31cc5e5c7b9d19c6b0a4c...
  • ben0x539 8y ago
    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 8y ago
      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`.