The idea of “name elision” has come up at least a few times across version forums; a good discussion occurred here (thread since closed): Name elision - #7 by josh
Tl;dr “name elision” refers to omitting the name of the type in a destructuring assignment where the type is known (which it usually is, because it's given by the right hand side of the assignment). Two prominent examples are fn f(_ {x, y, z}: MyType) and let _ { x, y, z } = my_type (where _ is inferred to be MyType) in both cases. Perhaps even match x { _::Variant1 => {}, _::Variant2 => {} because the enum type being matched against can be inferred from the type of x.
Despite not going anywhere in the past, this seems like a pretty popular request. What would it take to get this off the ground and into an RFC? As far as language semantics go, there's really not much change; just wherever the type on the LHS would have to be unified with the type on the RHS, instead the type on the LHS would be inferred to be the type on the RHS. It's just a matter of implementing this inference in the compiler.
If you read that full thread, there seemed to be consensus on name elision being permitted in pattern matching (but not consensus elsewhere). An RFC is on my to-do list, but it's nowhere near the top.
One good way to make progress on it would be to implement it in the compiler as an error with a structured suggestion when someone uses _ as the name of a struct (in either a pattern or an initializer), like how you can write -> _ on a function and the compiler will give a nice suggestion for what type to put there.
That's independently useful even if it never becomes not an error, and can land as soon as the compiler team is happy with the implementation, no FCPs required. And it conveniently also proves out that doing this is entirely feasible in inference (not that I expect there will be any problems in this case).
It makes me think of how vector<vector<int>> used to not work in C++ -- you had to say vector<vector<int> > -- but they made it work in large part because just about every compiler had already implemented it to give a nice error message anyway.
Just to give a quick update, I've got underscores in a type position in patterns to no longer fail to parse, and I'm working on replacing the path resolution errors that arise (e.g., “no struct _, found similar struct S”) with a path-will-be-inferred marker that gets resolved in HIR analysis or typeck (probably in collect or write back, respectively? Not sure yet.)
Hmm, does value position matching of _ result in an id node? I'm guessing it would result in a "discard" given the differing semantics. I ask because it sounds like you've gotten the parser to accept _ as a type path, rather than changing the type position in patterns to possibly be a "discard". (It might be quite a bit of churn though.)