Implement type ascription. #21836
Implement type ascription. #21836
Conversation
|
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
|
@SiegeLord had challenged me to this, and I will not be making a RFC myself as I've already spent more than the ten minutes I've allocated for it. |
|
cc @nick29581 |
|
I don't see any reason not to land this soon. But we should wait for an RFC first, I'll chat to Niko about priorities and can write one up if we decide to go for it. |
|
+1 |
|
RFC: rust-lang/rfcs#803 |
|
Closing in favor of the associated RFC |
|
@alexcrichton I don't understand - all of my changes are still necessary - is a complete RFC implementation expected in case of approval? |
|
Patches for major* features like this don't land until there's more consensus about the RFC. (*whether a feature is major or not is independent of the difficult of implementation.) |
|
Is then "in favor of" supposed to mean "pending resolution of"? That is fine with me. |
|
Yes sorry I'm just trying to keep the queue size down, it's fine to reopen this once the RFC is accepted. |
|
RFC was accepted, should this be reopened? cc #23416 |
|
What's the state of this? The opinion about type ascription seems to be positive overall. |
|
Overall looks good, I feel like a name like ExprAscribe (or something else) would be better, it wasn't clear to me that ExprType corresponds to type ascription when reading the code. I'm happy to r+ this if no one else has an issue. |
|
@jroesch There are several newer rebase attempts. |
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
|
@eddyb makes sense, this is a pretty straight forward thing to implement. |
|
(Note that this has now been implemented in #30184, but without the coercion aspect.) |
First iteration of type ascription in expressions. Syntax is
expr: Twith the same precedence asas.Shouldn't be backwards incompatible, but I've had to modify
asm!to not include colons in parsing.