Modify RFC #803 (type ascription) to make type ascription expressions lvalues

[nrc]

No description provided.

[nrc]

cc @eddyb @nikomatsakis

[huonw]

The history seems strange?

[nrc]

Yeah, I screwed the history up some how, I'll try to fix it at some point

[nrc]

Fixed the history and addressed @pnkfelix's comment

[Ericson2314]

+1 definitely an improvement. Would be nice if for the assignment case (<expr> = ...;), casting to a subtype was eventually supported.

[nikomatsakis]

Hear ye, hear ye. This RFC is entering the final comment period.

[huonw]

Just to clarify, this would allow writing the following?

let x;
x: i32 = 10;

[nikomatsakis]

This <expr> renders funny. You should add verbatim quotes.

[nikomatsakis]

I find this phrasing kind of odd, though I think I agree with the intention.

It seems odd to say that <expr>: T is always an lvalue. For example, is foo(): T an lvalue? The only way I can make sense of that is if <expr>: T puts <expr> into a temporary (when it is an rvalue) and then is equivalent to referencing that temporary.

My original thought was that <expr>: T would be an lvalue if <expr> is an lvalue, and an rvalue if <expr> is an rvalue. Moreover, there would be an additional rule that when <expr>: T appears in a ref context, the type of <expr> and T must match exactly (though, strictly speaking, I think it is ok to upcast if <expr> is an rvalue).

That said, I think that the "temporary interpretation" I gave above and my interpretation behave the same way from an end-user point of view. For example, if you write &(foo(): T), and you consider foo(): T to be an rvalue, then this will create a temporary with the enclosing temporary scope and store foo() in it. But if you take the first interpretation, it will also create a temporary and store foo() in it, and presumably the lifetime of that temporary would be the same (though we would probably want to adjust the temporary lifetime rules to "see through" <expr>: T).

Anyway, just for reference, let me define my terms a bit:

• lvalue: something that can be assigned to, e.g. x, x.f
• rvalue: something that cannot be assigned to, e.g. x()
• lvalue/ref context: something where you are taking the address, e.g. <expr> in &<expr> or in a match, etc.

[nikomatsakis]

Update: I realized that since lvalue controls what you can assign to, it definitely seems wrong to say that type ascription is always an lvalue, since that would permit foo(): T = 5.

I prefer just saying that it is an lvalue/rvalue based on the underlying expression, and that x: T = 5 is a reference context (and hence this annotation is basically an assertion that the type of x is T).

[nrc]

@huonw yes.

[nrc]

@nikomatsakis updated the text

[nikomatsakis]

It's official... the language subteam has decided to accept this RFC.