@@ -9,7 +9,7 @@ In order to prepare for an expected future implementation of
9
9
10
10
* moving individual elements into an * uninitialized* fixed-sized array, and
11
11
12
- * moving individual elements out of fixed-sized arrays ` [T, .. n] ` ,
12
+ * moving individual elements out of fixed-sized arrays ` [T; n] ` ,
13
13
(copying and borrowing such elements is still permitted).
14
14
15
15
[ non-zeroing dynamic drop ] : https://github.com/rust-lang/rfcs/pull/320
@@ -36,19 +36,24 @@ will present relatively little burden.
36
36
37
37
# Detailed design
38
38
39
- If an expression ` e ` has type ` [T, .. n] ` and ` T ` does not implement
39
+ If an expression ` e ` has type ` [T; n] ` and ` T ` does not implement
40
40
` Copy ` , then it will be illegal to use ` e[i] ` in an r-value position.
41
41
42
- If an expression ` e ` has type ` [T, .. n] ` expression ` e[i] = <expr> `
42
+ If an expression ` e ` has type ` [T; n] ` expression ` e[i] = <expr> `
43
43
will be made illegal at points in the control flow where ` e ` has not
44
44
yet been initialized.
45
45
46
46
Note that it * remains* legal to overwrite an element in an initialized
47
47
array: ` e[i] = <expr> ` , as today. This will continue to drop the
48
48
overwritten element before moving the result of ` <expr> ` into place.
49
49
50
- A prototype implementation will be made available before this RFC is
51
- accepted.
50
+ Note also that the proposed change has no effect on the semantics of
51
+ destructuring bind; i.e. ` fn([a, b, c]: [Elem; 3]) { ... } ` will
52
+ continue to work as much as it does today.
53
+
54
+ A prototype implementation has been posted at [ Rust PR 21930] .
55
+
56
+ [ Rust PR 21930 ] : https://github.com/rust-lang/rust/pull/21930
52
57
53
58
# Drawbacks
54
59
@@ -62,11 +67,13 @@ Also, as noted in the [comment thread from RFC PR 320]
62
67
[ comment thread from RFC PR 320 ] : https://github.com/rust-lang/rfcs/pull/320#issuecomment-59533551
63
68
64
69
* We support moving a single element out of an n-tuple, and "by
65
- analogy" we should support moving out of ` [T, ..n] `
70
+ analogy" we should support moving out of ` [T; n] `
71
+ (Note that one can still move out of ` [T; n] ` in some cases
72
+ via destructuring bind.)
66
73
67
74
* It is "nice" to be able to write
68
75
``` rust
69
- fn grab_random_from (actions : [Action , .. 5 ]) -> Action { actions [rand_index ()] }
76
+ fn grab_random_from (actions : [Action ; 5 ]) -> Action { actions [rand_index ()] }
70
77
```
71
78
to express this now, one would be forced to instead use clone() (or
72
79
pass in a ` Vec ` and do some element swapping).
0 commit comments