Tracking issue for RFC 803, "Type ascription"

[nikomatsakis]

Superseded by #101728 due to the landing of RFC 3307

Tracking issue for rust-lang/rfcs#803. Important points:

• Implement the expr:Type syntax
• 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()
• Permit coercions like &[1, 2, 3]: &[u8] -- permit coercion in type ascription #78248

[petrochenkov]

There's one thing making type ascription less convenient than it could potentially be. While it has the same operator priority as as (it is modeled after as in general), i.e. the highest from binary operators, it's still lower than member access . (dot).

Compare these two expressions

let v = v.iter().collect::<Vec<_>>().sort(); // Parens are not required
let v = (v.iter().collect(): Vec<_>).sort(); // Parens are required
// Formatted on several lines
let v = (v.iter().
           collect(): Vec<_>). // Looks bad, man
           sort();

I'm not sure if it is worth fixing or if it can be fixed without hacks, but it is worth discussing at least.

[hoodie]

BTW: This has is a breaking change for crates that implement a similar macro syntax already, such as prettytables.

[jonas-schievink]

@hoodie I opened #30531, since this seems worth tracking

[nrc]

cc @nrc

[vi]

Is it a good idea to only do ascription inside parentheses, so let a = x : T is not ascription yet, but let a = (x : T) is? This can allow more room for some further syntax additions.

[petrochenkov]

For the record: a patch implementing support for method chaining with type ascription #33380

[ottworks]

Why is this in the book if it won't compile? (1.9.0)

https://doc.rust-lang.org/book/closures.html

[hoodie]

@0TT what exactly?

[retep998]

@0TT Type ascription is specifically when adding a : T type annotation after an expression. Not in the parameters to a closure or a function, and not on a variable binding. Only when it follows an expression which I do not see any cases of on the page you linked.

[ottworks]

Oops. I accidentally typo'd a semicolon as a colon:

let plus_two = |x| {
    let mut result: i32 = x;

    result += 1:
    result += 1;

    result
};
assert_eq!(4, plus_two(2));

[hoodie]

that happens, how about an RFC to replace all semicolons with a less confusable character?

let plus_two = |x| {
    let mut result: i32 = x✓

    result += 1✓
    result += 1✓

    result
}✓
assert_eq!(4, plus_two(2))✓

makes the language even look safer, everything is checked after all 😀

[ottworks]

Should use emoji tbh. A language for the future.

[nrc]

re the soundness question in the OP, this comment is probably the best summary.

[crumblingstatue]

Before stabilizing this feature, I would like to see how this potentially impacts optional and named arguments, namely the expr : type syntax in function call argument position.

Could named arguments use this syntax if it wasn't for type ascription?

If yes, and no other syntaxes could be devised that are as optimal as name : type, I'd strongly recommend changing the syntax for type ascription, in favor of allowing the optimal syntax for named arguments.

I believe named arguments would be much more widely used than type ascription, and the syntax optimization for ergonomics should go there instead.

Ref rust-lang/rfcs#323

[misha-krainik]

@nikomatsakis could we improve error message in this case

proto::Status:ok()

I got

error[E0658]: type ascription is experimental (see issue #23416)
  --> src/main.rs:6:26
   |
76 |             status: Some(proto::Status:ok())
   |                          ^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(type_ascription)] to the crate attributes to enable

According this RFC type ascription should contain : and space between words. But it's spreading on typo mistake with ::

[Centril]

cc @estebank ^-- We discussed this at the all hands on a night out... the idea, if you remember, was that you check for this pattern when the LHS of : is valid under <LHS> and RHS is not an existing type.

[estebank]

@Centril I remember. I made #59150 with a different approach, more hacky but one that would have given the right error above.

[Centril]

@estebank Oh haha; I even reviewed that one... 😅

[estebank]

@Centril #62791 and #62816 should cover all of the (common) type ascription typos (: -> ;, foo(x: bar), foo:bar::baz(1), etc.). With that I believe that "diagnostics being terrible" is no longer a valid reason not to continue with the current syntax.

[pksunkara]

What are the things that needs to be done to make this stable?

[Centril]

It's stuck on finding consensus in rust-lang/rfcs#2522 plus making the necessary changes (+ writing a lot of tests for them) outlined here and there.

[ethindp]

Oh, whoops. I use a screen reader and I never have it set to announce all punctuation so I forgot the apostrophes. Perhaps we can add a suggestion inthe compiler if it sees that kind of pattern?

…

On 8/16/20, Charmander ***@***.***> wrote: @ethindp https://doc.rust-lang.org/stable/rust-by-example/flow_control/loop/nested.html: `func_loop:` → `'func_loop:` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #23416 (comment)

-- Signed, Ethin D. Probst

[ijackson]

It's stuck on finding consensus in rust-lang/rfcs#2522 plus making the necessary changes (+ writing a lot of tests for them) outlined here and there.

RFC 2522 has been postponed. I think that means we should consider whether to stabilise type ascription for expressions as currently implemented. Looking through this issue I found only the following outstanding concerns/objections:

• Is the precedence right? Tracking issue for RFC 803, "Type ascription" #23416 (comment)
• interaction with the idea of optional/named arguments (which might also use :)

There was also the soundness question summarised here rust-lang/rfcs#803 (comment) . But I think having read #78248 that in fact this soundness issue does not arise because we do not support coercion in type ascription. Supporting coercion might be nice but I don't think it should be a blocker for stablising this feature.

[nikomatsakis]

I opened #78248 which describes how (I think...) we can support coercions in a relatively straightforward way. I do think that coercions are an important part of this feature. However, there are some other concerns about the syntax that have been raised. Last time I checked we definitely did not have full consensus on going forward here.

[Manishearth]

Superseded by #101728 due to the landing of RFC 3307