Sometimes _ refers to an inferred type and sometimes it doesn’t. You can’t meaningfully search for '_' or 'underscore' in the reference to find out the rules. Anyway, such rules are a burden and learning obstacle. If there’s a concept, like “_ refers to the inferred type,” it should hold everywhere!
Types can often be rather lengthy, especially generic ones. In constructor type functions (which don’t return Self, e.g. typestate transitions,) as the last thing, one typically repeats the type verbosely. As a legacy of C++, which chose an operator as a bracket, don’t forget to turbofish it, no plain copy & paste! To avoid all that I wanted to infer it, but the compiler didn’t even understand. (The first variant might be unlikely to be used much, it’s just for completeness.)
fn f_unit() -> SomeLongnamedUnitType {
// SomeLongnamedUnitType
_
}
fn f_struct(x: f32) -> SomeComplicatedStruct<Type> {
// SomeComplicatedStruct::<Type> { x }
_ { x }
}
fn f_tuple(x: f32) -> SomeComplicatedTuple<Type> {
// SomeComplicatedTuple::<Type>(x)
_(x)
}
This should be logically unambiguous, and syntactically as well. The only other thing (???) that can currently have an underscore at the beginning of a statement is
_ = must_use_value();
So I suggest in all contexts where the expected type is clear, to generalise _ to be that type. Looking forward to a Rust that feels even more consistent.
