Ref/& Destructuring Inconsistency in Structs

[quantatic]

Rust pattern matching and destructuring allows the use of & and ref.

In the example below, the use of these is intuitive.

fn main() {
    let a: (u32) = (1234);
    let (ref ref_a) = a;

    let b: (&u32) = (&1234);
    let (&deref_b) = b;
}

In this case, we end up with ref_a of type &u32, and deref_b of type u32. Simple enough -- we can go both ways with both ref and & in pattern matching.

In the instance with structs, this consistency breaks down when matching struct field names. In the example that follows, this is shown:

struct Borrowed {
    val: u32
}

fn main() {
    let a = Borrowed {
        val: 1234
    };

    let Borrowed {ref val} = a;
}

In this case, val is borrowed as &u32, mirroring tuple functionality. The following example on the other hand, does not work.

struct Derefed<'a> {
    val: &'a u32
}

fn main() {
    let a = Derefed {
        val: &1234
    };

    let Derefed {&val} = a; // error: expected identifier, found `&`
    let Derefed {val: &val} = a; // works as expected
}

While not functionality-breaking, it is extremely non-intuitive that this matching only works via ref and not via & for structs, when binding directly to the same variable name.

[hadronized]

Capturing and destructuring are two different concepts. let Derefed { &val } = a is not a valid syntax for destructuring because val is a field. You cannot destructure a field the way you seem to want, for a very simple reason: imagine that the field was not a reference but an Option<_>. You wouldn’t use such a syntax, but more:

struct Foo {
    x: Option<u32>
}

fn main() {
  let f = Foo { x: Some(123) };
  
  if let Foo { x: Some(ref inner) } = f {
    println!("{}", inner);
  }
}

Why would it be any different for references?

[Pauan]

@phaazon I think you're misunderstanding their request. They are aware that & and ref are opposites.

What they are asking for is that the field short-hand syntax should be extended to support references.

Right now you can use the field short-hand syntax, such as Foo { bar }, which is equivalent to Foo { bar: bar }.

But that short-hand syntax does not work with references, so you cannot use Foo { &bar }, which would be equivalent to Foo { bar: &bar }.

[hadronized]

Ah, yeah, then I’m still against it. 😄 If that gets accepted, in five months from now, someone will complain they can’t do Foo { Some(bar) or something along these lines.

[quantatic]

Thank you for the clarification @Pauan -- apologies if my initial title was unclear/ambiguous.

Perhaps I'm unclear on the official naming convention, but as I understand it, the following example:

struct Test {
    a: i32
}

fn main() {
    let test = Test {
        a: 1234,
    };

    let Test {ref a} = test; //a is of type &i32 here.
}

Is an example of de-structuring the Test struct, and assigning the local variable a to the borrowed a field from the struct.

Currently, this short-hand syntax supports borrowing, but not de-referencing. To me, this seems unintuitive: almost everywhere else that a ref can be used for pattern matching/destructuring to borrow, a & can be used to de-reference.

I understand why this may confuse newcomers into believing this would work for an Option or similar enum, but even in that case, it is unclear to me why the fact that this currently supports ref is not be equally confusing.

[Pauan]

@quixotrykd Actually, you can already use & with Option (and any other enum):

let a = 5;

if let Some(ref b) = Some(a) {}
if let Some(&b) = Some(&a) {}

let ref b = Some(a);
let &b = &Some(a);

Using & works anywhere that a pattern works. So you are right that there is some inconsistency with struct fields.

[hadronized]

You are right about the fact that & can be used anywhere a pattern works. In let _ = _; the left _ is a pattern. Some(&b) is a pattern. Some(ref b) is a pattern (the Some(_)) but ref b states how we want to capture what we destructured in the pattern.

Deref { _ } is a pattern. However, what you put in the _ must be list of field-patterns. a: b is one and a is a short hand for a: a.

let Derefed {&val} = a; // error: expected identifier, found `&`

Here, &val is a pattern, not a field-pattern. If you want to make it a shorthand syntax for setting val as what’s behind the reference (i.e. &val), then since &val is a pattern, you’re also opening the gate to accepting any pattern here, such as:

struct Foo {
  a: Option<u32>
}

let Foo { Some(a) } = this_doe_not_make_sense;

Again, accepting &a here would be an exception — because &a means to destructure a field that is behind a reference and capturing its content at the same time — and is actually weirder than what you seem to think. What would you do with the Option example I gave you above?

[Pauan]

@phaazon Nobody is suggesting Foo { Some(a) } (and I would personally be against it if they did, that proposal makes no sense).

As for the inconsistency, I think you are misunderstanding something. Foo { _ } is not valid, because structs do not accept patterns, they only accept these special hard-coded things:

Foo { bar: <pattern> }
Foo { bar }          // equivalent to Foo { bar: bar }
Foo { ref bar }      // equivalent to Foo { bar: ref bar }
Foo { mut bar }      // equivalent to Foo { bar: mut bar }
Foo { ref mut bar }  // equivalent to Foo { bar: ref mut bar }
Foo { .. }           // ignores the fields

As you can see, structs do not use patterns, they have their own special struct-only syntax.

Notice that you can use Foo { ref bar } (which is equivalent to Foo { bar: ref bar }). This is using the field shorthand syntax, but with a ref (or mut) modifier. This syntax is an exception, it is special struct syntax, it is not a pattern.

So since we already have an exception for ref and mut, there is no problem with adding in another exception for &. And the behavior of Foo { &bar } is crystal clear, it behaves exactly like Foo { bar: &bar }.

And there is no risk of the slippery slope of "what if people ask to add in more exceptions later?" because there aren't any more exceptions: none of the other patterns make sense in field position, so & is the only field pattern currently missing from structs.

[hadronized]

My point was: if you add Foo { &bar }, since &bar is a pattern, you’re adding more inconsistency, because if we can pattern-match on &bar, it would feel consistent to try to pattern match on Option<_>. That’s why I don’t really like that proposal and also why I don’t agree with the OP that the current situation is inconsistent.

[Pauan]

@phaazon As I explained, we already have ref and mut as special patterns which work on struct fields. So adding in &bar is not making things more inconsistent than the status quo. On the contrary, it fills in the only missing pattern, since none of the other patterns make sense.

And I have found situations where & would have been useful in practice, so this isn't just a hypothetical benefit.

[Centril]

So adding in &bar is not making things more inconsistent than the status quo. On the contrary, it fills in the only missing pattern, since none of the other patterns make sense.

I disagree with this perspective and agree with @phaazon. If you look at the pattern grammar (and indeed the implementation), you will find that we have:

pat ::=
  | "&" "mut"? pat
  | "ref"? "mut"? ident
  | other_stuff_in_pat
  ;

As you can see, the non-terminal in the case of & is pat whereas it is ident in the case of ref.
In field short-hand patterns, you can also use the "ref"? "mut"? ident grammar. However, the proposal here is to allow "&" "mut"? ident. The non-terminal here is inconsistent with the non-short-hand version, which allows full-blown patterns.

[Pauan]

@Centril That is true, but I personally don't view that as being a problem or an inconsistency, because field patterns are already a subset of patterns, so there's no issue with having "&" "mut"? ident which is a subset of "&" "mut"? pat.

Or to put it another way, ident, "ref" ident, "mut" ident (etc.) are patterns, but they are also field patterns, and the behavior of field patterns is different than the behavior of patterns. So the same would be true for &.

So I find the objection of "it only allows a subset of patterns" to be weak, since that's already true today.

[Centril]

The desirable property in the record short-hand is that it reuses the grammar from "ref"? "mut"? ident exactly (and so it is complete from the perspective of covering binding patterns as a short-hand). My point was that the same cannot be said of "&" "mut"? ident. If you add that, there's no good reason from the POV of grammatical consistency not to allow &&x. I would however understand the argument "this is inconsistent, but ergonomics trumps consistency in this case".