Allow type ascription on patterns and expressions

[huonw]

It'd be nice if

for x: uint in something_generic() {
    more_generics(something_else_generic(x): f64)
}

allowed the programmer to give explicit type hints/annotations to patterns and expressions.

[thestinger]

+1, but I think we should hold off on adding more features to for loops as long as they're a parser expansion hack. There's a serious need to get this moved into the compiler to provide saner semantics and comprehensible error messages.

[huonw]

The for-loops would follow automatically from allowing it in patterns, i.e.

let ((a, b): (u8, uint), c) = ((1, 2), "foo");

would be handled by the same path.

[thestinger]

I don't think it currently has a let statement so it's going to make the unoptimized bytecode worse. I really want this in librustc with support for not borrowing from an lvalue, proper type checking for the iterator and saner code generation.

[huonw]

match foo {
   (x: u8, y) => { ... }
}

is also a pattern context.

[thestinger]

Ah, I didn't realize the type annotations worked there. That would be fine!

[glaebhoerl]

How tightly should type ascription bind? In Haskell it binds looser than everything else (so in a + b + c :: Int, it's a + b + c that's of type Int, not c), and this is sometimes what you want, but it's also frequently not.

[emberian]

cc @pcwalton (he wanted this)

[nikomatsakis]

I want this too. It's probably good enough to just allow type ascription on bindings, not on arbitrary patterns, which helps address @glehel's question of how tightly they should bind.

[nikomatsakis]

Have to think about how this interacts with the current let pat: type = ...;, syntax and in particular with type coercions that can occur there -- the current behavior would be harder to reproduce this way (though it can probably be done), because we'd have to deduce the type that the expression should have by "bubbling the types up" through the pattern, which we don't currently do -- instead our pattern code is hard-wired to push types down.

[japaric]

@nick29581 Should this be closed in favor of rust-lang/rfcs#354?

[nrc]

yes