From 906439df42ad86d8bb3ae6ffa27d32dd1823cd06 Mon Sep 17 00:00:00 2001 From: Nick Cameron Date: Wed, 18 Mar 2015 15:10:13 +1300 Subject: [PATCH 1/3] Modify RFC #803 (type ascription) to make type ascription expressions lvalues. --- text/0803-type-ascription.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/text/0803-type-ascription.md b/text/0803-type-ascription.md index aecc5f4586c..a79c213572b 100644 --- a/text/0803-type-ascription.md +++ b/text/0803-type-ascription.md @@ -172,10 +172,10 @@ lvalue position), then we don't have the soundness problem, but we do get the unexpected result that `&(x: T)` is not in fact a reference to `x`, but a reference to a temporary copy of `x`. -The proposed solution is that type ascription expressions are rvalues, but -taking a reference of such an expression is forbidden. I.e., type asciption is -forbidden in the following contexts (where `` is a type ascription -expression): +The proposed solution is that type ascription expressions are lvalues, where +the type ascription expression is in reference context, then we require the +ascribed type to exactly match the type of the expression, i.e., neither +subtyping nor coercion is allowed. These contexts are: ``` &[mut] @@ -184,12 +184,6 @@ match { .. ref [mut] x .. => { .. } .. } .foo() // due to autoref ``` -Like other rvalues, type ascription would not be allowed as the lhs of assignment. - -Note that, if type asciption is required in such a context, an lvalue can be -forced by using `{}`, e.g., write `&mut { foo: T }`, rather than `&mut (foo: T)`. - - # Drawbacks More syntax, another feature in the language. From 18fe78ed3e1611be4ee5484b4b5e9d18e0c534b3 Mon Sep 17 00:00:00 2001 From: Nick Cameron Date: Tue, 24 Mar 2015 12:35:37 +1300 Subject: [PATCH 2/3] Update the text about lvalues --- text/0803-type-ascription.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/text/0803-type-ascription.md b/text/0803-type-ascription.md index a79c213572b..94dc373d59c 100644 --- a/text/0803-type-ascription.md +++ b/text/0803-type-ascription.md @@ -172,16 +172,18 @@ lvalue position), then we don't have the soundness problem, but we do get the unexpected result that `&(x: T)` is not in fact a reference to `x`, but a reference to a temporary copy of `x`. -The proposed solution is that type ascription expressions are lvalues, where -the type ascription expression is in reference context, then we require the -ascribed type to exactly match the type of the expression, i.e., neither -subtyping nor coercion is allowed. These contexts are: +The proposed solution is that type ascription expressions are lvalues. If the +type ascription expression is in reference context, then we require the ascribed +type to exactly match the type of the expression, i.e., neither subtyping nor +coercion is allowed. These reference contexts are as follows (where is a +type ascription expression): ``` &[mut] let ref [mut] x = match { .. ref [mut] x .. => { .. } .. } .foo() // due to autoref + = ...; ``` # Drawbacks From d69cf9248e992b2679f444e4a591c892df3e08f6 Mon Sep 17 00:00:00 2001 From: Nick Cameron Date: Wed, 10 Jun 2015 15:11:08 +1200 Subject: [PATCH 3/3] Clarify text about lvalues --- text/0803-type-ascription.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/text/0803-type-ascription.md b/text/0803-type-ascription.md index 94dc373d59c..e5e62c37ad2 100644 --- a/text/0803-type-ascription.md +++ b/text/0803-type-ascription.md @@ -153,10 +153,10 @@ context of cross-platform programming). ### Type ascription and temporaries There is an implementation choice between treating `x: T` as an lvalue or -rvalue. Note that when a rvalue is used in lvalue context (e.g., the subject of -a reference operation), then the compiler introduces a temporary variable. -Neither option is satisfactory, if we treat an ascription expression as an -lvalue (i.e., no new temporary), then there is potential for unsoundness: +rvalue. Note that when an rvalue is used in 'reference context' (e.g., the +subject of a reference operation), then the compiler introduces a temporary +variable. Neither option is satisfactory, if we treat an ascription expression +as an lvalue (i.e., no new temporary), then there is potential for unsoundness: ``` let mut foo: S = ...; @@ -172,11 +172,13 @@ lvalue position), then we don't have the soundness problem, but we do get the unexpected result that `&(x: T)` is not in fact a reference to `x`, but a reference to a temporary copy of `x`. -The proposed solution is that type ascription expressions are lvalues. If the -type ascription expression is in reference context, then we require the ascribed -type to exactly match the type of the expression, i.e., neither subtyping nor -coercion is allowed. These reference contexts are as follows (where is a -type ascription expression): +The proposed solution is that type ascription expressions inherit their +'lvalue-ness' from their underlying expressions. I.e., `e: T` is an lvalue if +`e` is an lvalue, and an rvalue otherwise. If the type ascription expression is +in reference context, then we require the ascribed type to exactly match the +type of the expression, i.e., neither subtyping nor coercion is allowed. These +reference contexts are as follows (where `` is a type ascription +expression): ``` &[mut]