Tracking issue for RFC 803, "Type ascription" #23416
Comments
This PR is a rebase of the original PR by @eddyb #21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below. This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided. So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all. In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone. Part of #23416
There's one thing making type ascription less convenient than it could potentially be. While it has the same operator priority as Compare these two expressions
I'm not sure if it is worth fixing or if it can be fixed without hacks, but it is worth discussing at least. |
BTW: This has is a breaking change for crates that implement a similar macro syntax already, such as prettytables. |
cc @nrc |
Is it a good idea to only do ascription inside parentheses, so |
For the record: a patch implementing support for method chaining with type ascription #33380 |
Why is this in the book if it won't compile? (1.9.0) |
@0TT what exactly? |
@0TT Type ascription is specifically when adding a |
Oops. I accidentally typo'd a semicolon as a colon:
|
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 |
Should use emoji tbh. A language for the future. |
re the soundness question in the OP, this comment is probably the best summary. |
Before stabilizing this feature, I would like to see how this potentially impacts optional and named arguments, namely the 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 I believe named arguments would be much more widely used than type ascription, and the syntax optimization for ergonomics should go there instead. |
I think @scottmcm's plan sounds good. Repeating what I said on #rust-lang: I can live with the problem of not having 100% consistency personally. Some inconsistency is to me better than not having the feature at all. Unfortunately, with the current language and our backwards compatibility promises, we can't achieve 100% consistency with typing judgements in the language across the board and I'm not advocating that we write: let foo as type = expr; That said, I think the idea due to @cramertj to have some sort of An example: let vec = iter.map(..).filter(..).collect().at!(Vec<u32>); The benefit of post macros here is that it allows chaining... however, I think it is unlikely to have many type ascriptions per expression. |
The top level message shouldn't be too long; the replaced-by-coercion/temporary-variable advice can live in a note. Also, don't mention type ascription when it's not actually available as a real thing. (The current state of discussion on the type ascription tracking issue rust-lang#23416 makes one rather suspect it will never be a stable thing in its current form, but that's not for us to adjudicate in this commit.)
The top level message shouldn't be too long; the replaced-by-coercion/temporary-variable advice can live in a note. Also, don't mention type ascription when it's not actually available as a real thing. (The current state of discussion on the type ascription tracking issue rust-lang#23416 makes one rather suspect it will never be a stable thing in its current form, but that's not for us to adjudicate in this commit.)
The top level message shouldn't be too long; the replaced-by-coercion/temporary-variable advice can live in a note. Also, don't mention type ascription when it's not actually available as a real thing. (The current state of discussion on the type ascription tracking issue rust-lang#23416 makes one rather suspect it will never be a stable thing in its current form, but that's not for us to adjudicate in this commit.) While we're here, yank out the differentiating parts of the numeric/other conditional and only have one codepath emitting the diagnostic.
As a long-time user of Scala, I have only very rarely seen anyone confuse (Numeric types in Scala have a notion of "weak conformance" which means they can get coerced unexpectedly; this has turned into a a fruitful source of puzzlers. Rust has much less of an issue presently, but dropping the distinction between pure ascription and request for coercion is likely to erode the improvement. It would be especially pernicious if the very thing you would use to check your assumptions could break them instead!) |
@nikomatsakis could we improve error message in this case
I got
According this RFC type ascription should contain |
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 |
@estebank Oh haha; I even reviewed that one... |
What are the things that needs to be done to make this stable? |
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. |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
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
|
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:
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. |
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. |
Tracking issue for rust-lang/rfcs#803. Important points:
expr:Type
syntaxref
positions:let ref x = <expr>
/let mut ref = <expr>
match <expr>: Type { ref x => ... }
(<expr>: Type).method_with_ref_self()
&[1, 2, 3]: &[u8]
-- #78248The text was updated successfully, but these errors were encountered: