Skip to content

Commit f5a6bd5

Browse files
committed
Move unresolved ATC question to proper section
1 parent 7914e65 commit f5a6bd5

File tree

1 file changed

+6
-5
lines changed

1 file changed

+6
-5
lines changed

text/0000-variadic-generics.md

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -66,10 +66,6 @@ trait Tuple {
6666
}
6767
```
6868

69-
TODO: should the above use `TupleRef<'a>` and `TupleMut<'b>` traits to avoid
70-
dependency on ATCs? It seems nicer to have them all together in one trait, but
71-
it's probably not worth the resulting feature-stacking mess.
72-
7369
The types `AsRefs` and `AsMuts` are the corresponding tuples of references to
7470
each element in the original tuple. For example,
7571
`(A, B, C)::AsRefs = (&A, &B, &C)` and
@@ -199,10 +195,15 @@ unified `Tuple`.
199195

200196
# Unresolved questions
201197
[unresolved]: #unresolved-questions
202-
It might be useful in the future to expand on the locations where `...Type`
198+
-It might be useful in the future to expand on the locations where `...Type`
203199
can be used. Potential extensions to this RFC could allow `...Type` in
204200
non-tuple generics or in function argument types, like
205201
`fn foo<Args>(args: ...Args)`.
206202
This would allow functions and traits to use variadic generics without
207203
explicit tuples. This could enable things like the proposed `foo[i, j]` syntax
208204
using`Index<usize, usize>`.
205+
-Should the `Tuple` trait use separate `TupleRef<'a>` and `TupleMut<'b>` traits
206+
to avoid dependency on ATCs? It seems nicer to have them all together in one
207+
trait, but it might not be worth the resulting feature-stacking mess.
208+
209+

0 commit comments

Comments
 (0)