Type ascription (ascription of patterns)

[nrc]

Post-1.0, we would like to allow arbitrary type ascription - that is annotating any expression with a type. E.g., let _ = foo(x, y: Bar<int>, z); (type ascription on the sub-expression y).

Detail to be nailed down - precedence (probably the same as as).

Optional extra - type ascription on patterns, e.g. let (x: Bar<int>, y) = foo(...); - useful when you care about the type of some part of the pattern but not others, especially when the bits you don't care about are _.

Optional, optional extra - using the ascribed types in pattern matching for downcasting (an extension of some #349 proposals).

[brendanzab]

👍

Generalizing the (:) operator would be nice. How does it interact with the struct field matching syntax though?

struct Foo<T> { a: i32, b: T }
let foo = Foo { a: 1, b: 2.0 };
let Foo { a: x, b: y: f32 } = foo;

[huonw]

@bjz the identifiers in the shorthand let Foo { a, b } = foo; are not full patterns, so it's not necessarily crazy for us to just require the form you have written (i.e. let Foo { a: i32, .. } is binding the value of the field a to the identifier i32, not type ascription). This should definitely be discussed in a detailed description of this feature, though.

[nrc]

See also some discussion on rust-lang/rust#10502

[1fish2]

What's the compelling reason for these features?

I can see how type ascription could enable safer patterns, but in expressions it seems like excess syntax sugar and complexity.

Benefits

• expression: type is more concise than let v: type = expression; v

The alternative is to write an ordinary let statement or (in some cases) expression as type or a literal with suffix like 0i16.

Costs

• Makes learning the language harder.
• May confuse people when reading unfamiliar code.
• Adds complexity to the language spec, tutorials, books, API docs, sample code, and published articles.
• Adds complexity to every compiler, language test suite, refactoring editor, program analysis tool, syntax-directed editor, and syntax-coloring web site (like GitHub).
• Prevents using the usual key: value syntax for default function arguments.
• May interact with other future syntax.
• Enables scary looking code like this:

SomeStruct {
  key1: value1: type1,
  y: y: Bar<int64>
}

Rust aims to be a production language that's predictable and reliable for security-critical and safety-critical software. Be careful about adding features from research languages like Haskell and Scala.

[brendanzab]

Be careful about adding features from research languages like Haskell and Scala.

Rust has tons of features from 'research languages', and is all the better for it, especially when it comes to safety and security.

[1fish2]

Indeed. Borrow the ideas that have proven out.

[japaric]

There is an implementation in rust-lang/rust#21836

Indeed. Borrow the ideas that have proven out.

Type annotation/ascription is one of the oldest ideas in programming languages.

[1fish2]

@darinmorrison for anonymous expressions? And proven worthwhile? Do say more.

Google mostly turns up info like the Scala Style Guide:

Ascription is basically just an up-cast performed at compile-time for the sake of the type checker. Its use is not common, but it does happen on occasion.

Criteria for language features should include usability, high bang/buck for the ecosystem, and not interfering with future plans. Apparently, type ascription for expressions is rarely used in Scala and accomplishes no more than using two orthogonal features together.

Optional extra - type ascription on patterns", e.g. let (x: Bar<int>, y) = foo(...);

That seems to be a declaration for a let binding rather than ascription.

[codyps]

@1fish2 I asked about something like this on IRC several months ago. The solution suggested to me was to add a macro to accomplish typing expressions. If we don't have support for it in the language, people will add a macro for it to individual projects, and all your arguments about confusion still apply or are made worse (naming and syntax could vary across codebases.

An obvious alternative would be a standard macro that supplies the functionality, but I'm not sure if that's really a better choice than adjusting the syntax.

Also, I'd be careful to note that your example with a struct is not necessarily something we expect (unless I'm a fool and those internal struct members are somehow expressions). As @huonw mentioned, we'll need to figure out if that makes sense (as a separate concern from being able to apply : to expressions)

@1fish2 Yes. The idea is about as old as types themselves. It may not have been common in some of the most popular languages but that doesn't have any bearing on its utility.

One strong argument in favor of allowing inline annotations is that it opens up options for making the type system more flexible, and potentially simplifying it even. If Rust ever adopts a bidirectional typing algorithm internally (I don't know what it currently uses), having these annotations will likely be important. (Some detail here and here). Top-level annotations are not always natural to use and may not even be feasible in some cases.

Advocating for keeping the language simple and avoiding unnecessary features is admirable but I don't see this one as being a problem, at least not in the sense you have suggested so far.

[1fish2]

+1. Go for a standard macro. That avoids the problems and costs.

Programmers can handle a great deal of complexity so it takes much restraint to avoid adding little features one by one that build up enormous complexity and sharp edges, like C++. Usability death by a thousand additions.