Allow inferring enum variant types with `_::Variant` syntax

[fourbytes]

I’ve recently been bouncing between Swift and Rust and have found the shorthand .variant syntax to be very useful. Having something similar in Rust would be very nice to have.
As initially suggested in #2830, the proposal is to allow explicitly inferring types for enum variants by using a _:: prefix.

Examples

enum CompassPoint {
    North,
    South,
    East,
    West
}

let mut direction = CompassPoint::West;
direction = _::East;

match point {
  _::East => { ... }
  _::West => { ... }
  _ => { ... }
}

fn function(cp: CompassPoint) {}

let direction = _::West;
function(direction);

[Fishrock123]

You should already be able to import enum variants directly:

use CompassPoint::West

[shepmaster]

You should already be able to import enum variants directly:

That's true, but importing the variants can cause other name clashes:

struct Fahrenheit(f32);
struct Celcius(f32);

enum Temperature {
    Fahrenheit(Fahrenheit),
    Celcius(Celcius),
}

impl Temperature {
    fn flip(self) -> Self {
        match self {
            Self::Fahrenheit(f) => Self::Celcius(Celcius(todo!("math"))),
            Self::Celcius(f) => Self::Fahrenheit(Fahrenheit(todo!("math"))),
        }
    }
}

If we import the variants:

impl Temperature {
    fn flip(self) -> Self {
        use Temperature::*;
    
        match self {
            Fahrenheit(f) => Celcius(Celcius(todo!("math"))),
            Celcius(f) => Fahrenheit(Fahrenheit(todo!("math"))),
        }
    }
}

error[E0308]: mismatched types
  --> src/lib.rs:14:38
   |
14 |             Fahrenheit(f) => Celcius(Celcius(todo!("math"))),
   |                                      ^^^^^^^^^^^^^^^^^^^^^^ expected struct `Celcius`, found enum `Temperature`

error[E0308]: mismatched types
  --> src/lib.rs:15:38
   |
15 |             Celcius(f) => Fahrenheit(Fahrenheit(todo!("math"))),
   |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `Fahrenheit`, found enum `Temperature`

Something like _:: would work because it doesn't cause conflicts.

As a workaround, I sometimes rename the enum to something short:

impl Temperature {
    fn flip(self) -> Self {
        use Temperature as E;
    
        match self {
            E::Fahrenheit(f) => E::Celcius(Celcius(todo!("math"))),
            E::Celcius(f) => E::Fahrenheit(Fahrenheit(todo!("math"))),
        }
    }
}

This proposal would allow omitting the use Temperature as E; line.

[Fishrock123]

Ah I think I understand better now - the _ would be scoped to the type in the match. I agree this (or something like it) would be very nice!

[leonardo-m]

If no significant troubles will be found with this syntax, I think this idea will eventually be implemented in Rust. It's sufficiently natural, it doesn't increase the amount of Rust grammar/syntax to remember, and in some situations it removes useless redundancy. A disadvantage is that in some cases it's less obvious for the person that reads the code what the enum is. So, as usual, common sense is required to the programmer to avoid puzzle-style coding.

[jhpratt]

Just for reference I'm starting to write an RFC that would permit this in patterns (nb: not construction).

[GoldsteinE]

@jhpratt Hi! Are you still working on that RFC? I’m willing to try to write this if nobody is doing it currently.

[berkus]

This looks very convenient indeed!

[jhpratt]

@GoldsteinE go for it!

[Fishrock123]

Sorry to be another person on this, but I have a lot of free time right now and also past RFC experience...

@GoldsteinE are you still working on this or can I pick it up?

Did anyone write anything down yet?

[GoldsteinE]

Hi! Sorry, I too got distracted from writing this (and also I don’t have RFC experience yet). @Fishrock123 you can take it.

[Fishrock123]

Pre-RFC up on the internals forum: https://internals.rust-lang.org/t/pre-rfc-inferred-enum-types/16100

[8573]

Circa 2020 I was in favor of this, but now I think this trades too much explicitness for too little added convenience compared to the existing option of the following:

use Direction as D;
match dir {
  D::North => { ... }
  D::East => { ... }
  D::South => { ... }
  D::West => { ... }
}

[berkus]

Circa 2020 I was in favor of this, but now I think this trades too much explicitness for too little added convenience compared to the existing option of the following:

use Direction as D;
match dir {
  D::North => { ... }
  D::East => { ... }
  D::South => { ... }
  D::West => { ... }
}

sooo....

match dir in Direction {
    _::North => { .. }
    _::East => { .. }
    _::South => { .. }
    _::West => { .. }
}

[rami3l]

Circa 2020 I was in favor of this, but now I think this trades too much explicitness for too little added convenience compared to the existing option of the following:

use Direction as D;
match dir {
  D::North => { ... }
  D::East => { ... }
  D::South => { ... }
  D::West => { ... }
}

sooo....

match dir in Direction {
    _::North => { .. }
    _::East => { .. }
    _::South => { .. }
    _::West => { .. }
}

Looks like you just want a syntax sugar of the following:

{
  use Direction::*;
  match {
    North => { .. }
    East => { .. }
    South => { .. }
    West => { .. }
  }
}

... and that takes us back to #2830.

[jhpratt]

There's other places than match, though. What about if let Some(_::East) = maybe_dir {}? Generalizing to anywhere patterns are permitted seems reasonable.