[Draft] RFC: Generalized Type Ascription

[Centril]

This is a draft version of an RFC for you to review, before a formal proposal is made for consideration.

Summary

This RFC supersedes and subsumes RFC 803. We finalize a general notion of type ascription uniformly in patterns, expressions, let bindings, and fn definitions. You may now for example write:

let x = (0..10).collect() : Vec<_>;

do_stuff(try : Option<u8> { .. });

do_stuff(async : u8 { .. });

do_stuff(unsafe : u8 { .. });

do_stuff(loop : u8 { .. });

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

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

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

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

Here, the underlined bits are patterns. Note however that this RFC does not introduce global type inference.

Finally, we lint (warn-by-default) when a user writes Foo { $field: $ident : $type } and the compiler instead suggests: Foo { $field: ($ident : $type) }.

[scottmcm]

nit: When I google "TDD" I get test driven development, as I expected, so I would discourage this abbreviation.

[scottmcm]

I think this would be hard right now unless it's a trait impl, so you might want to have the code example explicitly be such, or change the error to just say that you need types, without suggesting them. (Especially since diagnostic quality is something that doesn't need RFCing -- people will just make it better even if the RFC doesn't say so, in the cases that are feasible.)

[Centril]

Nuanced the language a bit here to make it optional :)

[nrc]

Big 👍 from me!

It's probably worth discussing the implementation status of rust-lang#803 in more detail, iirc, non-coercing ascription is implemented, but coercions are not. (As an alternative design, it might be worth considering different ways that coercion and ascription interact. Some people have wanted to keep ascription meaning no coercion, and only coerce with as, however, this doesn't work for some coercions from fixed size to dynamically sized types).

[nrc]

ANother benefit (which I don't think was ni 803) is that when you get a gnarly type error, type ascription can quickly help you understand and narrow down the error.

[kennytm]

The function names in the comments are all incorrect :)

[Centril]

Thanks for spotting this! Fixed :)

[kennytm]

The issue currently blocking type ascription (rust-lang/rust#23416) is soundness issue when coercion happens:

Ensure soundness with respect to ref positions:

• let ref x = <expr> / let mut ref = <expr>
• match <expr>: Type { ref x => ... }
• (<expr>: Type).method_with_ref_self()

The issue is elaborated in rust-lang#803 (comment) and rust-lang/rust#23416 (comment). It seems this RFC did not address this issue (can't find the word "sound" and this RFC does support coercion).

[scottmcm]

Are you certain it's the same between ref and &? In

let &x : &i32 = &0;

the x is an i32, so I think the parse is let (&x) : &i32, not let &(x: &i32).

[varkor]

Still true as of 2018-08-07 😁

[scottmcm]

While I really like this feature, it might be worth scoping it down initially to avoid needing to specify all the details. For example, there are no examples of lifetimes, thus far. (And I think it'd work fine, but there are a bunch of questions around things like lifetime elision if you have Foo { x: x: &i32, y: y: &i32 } and it's Foo<'_>.)

Maybe start with just the "no generics" case? (Like Quux below.)

[scottmcm]

...or you could just define the full unification algorithm 🤣

[varkor]

"wherefore" isn't quite right here ("therefore" is closer, but still awkward). Maybe rephrase to something like: "While at this stage Rust does not support type-level methods (meaning this parse currently makes no sense), a user may nonetheless make this mistake."

[scottmcm]

Wow, this section is awesome!

I think I agree with all of them except for good_11: I would expect that

fn good_11(Wibble(x: &i32, y: Bar<'_>)) {}

is equivalent to

fn good_11(Wibble(x: &'_ i32, y: Bar<'_>)) {}

is equivalent to

fn good_11<'a, 'b>(Wibble(x: &'a i32, y: Bar<'b>)) {}

Which is illegal since it, unlike Wibble, doesn't require that 'a == 'b.

That's because the version not wrapped in Wibble:

fn rutabaga(x: &i32, y: Bar<'_>) {}

would have two lifetimes, so I think the wrapped version should too.

This helps local reasoning, as you don't need to look at the declaration of Wibble to know whether the two lifetimes are the same or different (since Product and Wibble cases look the same in the function header).

--

So maybe then there's

fn good_11<'a>(Wibble(x: &'a i32, y: Bar<'a>)) {}

and

fn bad_4(Wibble(x: &i32, y: Bar<'_>)) {} //~ ERROR insufficiently constrained

[Centril]

Glad you think so :)

I agree that good_11 is the tricky one. The rule you imposed certainly does improve local reasoning and the expectation induced by rutabaga does seem like it would happen to folks sometimes.

However, I do wonder if people care and think so much about lifetime parameters (if you are dealing with unsafe code where this is important you should quantify explicitly) that it matters in practice. I mostly don't think about them that much personally.

• At the call site good_11 won't be callable with something where given &'a i32 and Bar<'b> you have that 'a != 'b because you won't be able to construct such a Wibble<'?> in the first place.

• What remains is then confusion at the definition site of good_11 where the user may think that 'a != 'b. However, when the user actually tries to make use of this mistaken belief, the compiler should be able to give the user the actual signature of the function and/or say that the lifetimes are really the same. Thus, the user can therefore "learn on the job".

In any case, it is also true that your proposed rule allows strictly less than my rule so if we use your rule and then change our minds we can switch. So we are forward compatible.

Finally and as an aside, there are two ways to make your changed good_11 shorter:

// in-band lifetimes (assuming we don't ditch it)
fn good_11(Wibble(x: &'a i32, y: Bar<'a>)) {}

// The types are fully determined by `Wibble<'_>` itself.
fn good_11(Wibble(x, y)) {}

EDIT: Perhaps the last one is so ergonomic that fn good_11(Wibble(x: &i32, y: Bar<'_>)) simply doesn't occur for it to matter?

I'll go and add an unresolved question for now; I think this is something which is subtle and where we'll want to weigh the trade-offs and discuss them on the RFC. :)

[scottmcm]

I think that

fn good_11(Wibble(x, y)) {}

should be rejected for the same reason that we now require -> Foo<'_> instead of just -> Foo: the existence of a lifetime should be visible in the function header.

So I still think the answer is that elision fills in lifetimes before the unification algorithm runs. and then the fn arugula(Wibble(x, y)) {} example an error because the unification algorithm doesn't find anything for the lifetime variables to unify with, and thus the signature is under-constrained.

[scottmcm]

...and I thought of more stuff for these examples: match ergonomics.

I think the following would work?

fn good_13(Foo(x): &_) {}

Giving a type of for<'a> fn(&'a Foo) and, in the body, x: &'a usize.

[varkor]

*too many

[Centril]

Thanks all for chipping in! Time to publish :)