RFC: Generalized Type Ascription

[Centril]

🖼️ Rendered

📝 Summary

This RFC supersedes and subsumes RFC 803. It generalizes existing type ascription in let bindings to everywhere a pattern can occur and makes some changes to ascription in expressions. You may now for example write:

let x = (0..10)
    .map(some_computation)
    .collect() : Result<Vec<_>, _>
    .unwrap()
    .map(other_computation) : Vec<usize>
    .into() : Rc<[_]>;

let alpha: u8 = expr;
    ^^^^^^^^^

let [x: u8, y, z] = stuff();
    ^^^^^^^^^^^^^

if let Some(beta: u8) = expr { .. }
            ^^^^^^^^

for x: i8 in 0..100 { .. }
    ^^^^^

fn foo(Wrapping(alpha: usize): Wrapping<usize>) {}
       ^^^^^^^^^^^^^^^^^^^^^^

Here, the underlined bits are patterns.

Finally, when a user writes Foo { $field: $pat : $type }, and when $pat and $type are syntactically α-equivalent, the compiler emits a warn-by-default lint suggesting: Foo { $field: ($pat : $type) }.

💖 Thanks

To @nrc, @kennytm, @varkor for reviewing the draft version.
To @scottmcm in particular for reviewing and being my rubber duck wrt. type inference.

Edit: Direct link to the pFCP checkboxes: #2522 (comment)

[comex]

We could easily add a trait

pub Identity { fn identity(self) -> Self { self } }
impl<T> Identity for T {}

That still would not allow .identity::<i32>() because turbofish on a method only allows specifying parameters on the method itself, not the trait the method came from. You'd have to do something hacky like

pub trait Is<T> {}
impl<T> Is<T> for T {}
pub trait HackyIdentity: Sized {
    fn identity<T>(self) -> Self where Self: Is<T> {
        self
    }
}
impl<T> HackyIdentity for T {}

[mark-i-m]

I still prefer generalized ascription, but one alternative that solves part of the motivation of this issue might be to allow turbofish to be used for trait methods. For example something like this (syntax is bikeshedable):

trait Bar {
  fn bar<T, U, V>(args: (T, U, V));
}

foo.bar::<as Bar, T, U, V>(args);

[dralley]

I'm interested in this RFC, what is the status? It's been 4 months since last comment.

[ExpHP]

rfcbot's last comment is now hidden under the fold:

#2522 (comment)

There are five concerns currently marked as unresolved.

[joshtriplett]

(Checking @aturon's box, as he's no longer on the lang team.)

[nikomatsakis]

@rfcbot fcp cancel

I'm going to cancel the FCP on this issue because it's very old. In fact, I'm planning to close this RFC as "postponed". The feature described within still seems potentially desirable, but it's clear that there is plenty of follow-up work to do. I would like to encourage anyone who wants to pursue this design to try and do so through the new, experimental lang-team MCP process described in RFC #2936. One other thought is that it is likely possible to extract some subset of the functionality described in this RFC and move that forward rather than trying to do all the work at once.

[rfcbot]

@nikomatsakis proposal cancelled.

[nikomatsakis]

As stated above, I'm also going to close this RFC as "postponed" -- if you'd like to pick up activity here, please do reach out on Zulip or consider opening an MCP, and we can discuss whether there is a good candidate to serve as an active liaison. Thanks. ❤️

[jtmoon79]

I ran into this problem and posted a SO question about it regarding variable ascription in for loops.

FWIW, I wrote in the question:

Why explicitly annotate i?

Often the original type is declared or annotated in some far away source code, like maybe in a different crate.

1. Sometimes, my IDE isn't able to deduce the type despite the code being compileable.
2. Code reviewing humans are unable to deduce the expected type (they are not viewing the code with the help of Intellisense popups).

Being explicit about the type can be helpful.