Skip to content

Commit 3ede8f1

Browse files
committed
Leave the syntax as a partially unresolved question
We had in this RFC chosen `impl use<..> Trait`. But there's been meaningful discussion about whether this should instead be `use<..> impl Trait`, so let's mark this question as unresolved.
1 parent de7a342 commit 3ede8f1

File tree

1 file changed

+18
-3
lines changed

1 file changed

+18
-3
lines changed

text/3617-precise-capturing.md

+18-3
Original file line numberDiff line numberDiff line change
@@ -750,7 +750,7 @@ We considered a number of different possible syntaxes before landing on `impl us
750750

751751
### `impl use<..> Trait`
752752

753-
This is the syntax chosen in this RFC.
753+
This is the syntax used throughout this RFC (but see the [unresolved questions][]).
754754

755755
Using a separate keyword makes this syntax more scalable in the sense that we can apply `use<..>` in other places.
756756

@@ -893,14 +893,14 @@ If these generics are more like the generic *arguments* above (*Intuition #1*),
893893

894894
However, if these generics are more like the generic *parameters* above (*Intuition #2*), then `use<..> impl Trait` makes more sense. In Rust, when we're putting generic parameters into scope, they appear before the type.
895895

896-
Since both intuitions are valid, but each argues for a different syntax choice, picking one is tough. The authors are sympathetic to both choices. The key historical and tiebreaker factors leading to our choice of the `impl use<..> Trait` syntax in this RFC are:
896+
Since both intuitions are valid, but each argues for a different syntax choice, picking one is tough. The authors are sympathetic to both choices. The key historical and tiebreaker factors leading to our use of the `impl use<..> Trait` syntax in this RFC are:
897897

898898
- The original longstanding and motivating semantic intuition for this feature was *Intuition #1*, and it argues for this syntax. The second intuition, *Intuition #2*, was only developed in the process of writing this RFC and after most of this RFC had been written.
899899
- The `use<..> impl Trait` syntax was never proposed before this RFC was written (it may have been inspired by the presentation in this RFC of the second intuition), and in discussion, no clear consensus has yet emerged in its favor.
900900
- There are some practical costs that exist for `use<..> impl Trait` that don't for `impl use<..> Trait`.
901901
- The "obvious" syntax for this feature is `impl<..> Trait`. We may yet someday want to switch to this, and migrating from `impl use<..> Trait` seems like a smaller step.
902902

903-
We are *not* leaving this as an open question, because given that there have already been substantial and productive discussions on this topic, and given that it's a bit of a coin flip where we're likely to be happy at the end of the day with either choice, it seems better to just pick one. But all questions are in some sense open until stabilization, if feelings shift far enough and an alternate consensus emerges, and the authors hope that people will take the opportunity to experiment with and experience the syntax on nightly.
903+
Nonetheless, we leave this as an [unresolved question][].
904904

905905
### `impl Trait & ..`
906906

@@ -940,6 +940,21 @@ We could use a new short keyword such as `via`. This has the number 1 and 2 dra
940940

941941
We could say `use('t, T)` or `use['t, T]`. However, in Rust today, generic parameters always fall within angle brackets, even when being applied to a type. Doing something different here could feel inconsistent and doesn't seem warranted.
942942

943+
# Unresolved questions
944+
[unresolved question]: #unresolved-questions
945+
[unresolved questions]: #unresolved-questions
946+
947+
## Syntax question
948+
949+
We leave as an open question which of these two syntaxes we should choose:
950+
951+
1. `impl use<..> Trait`
952+
- This syntax is used throughout this RFC.
953+
2. `use<..> impl Trait`
954+
- This syntax is the worthy challenger.
955+
956+
See the [alternatives][] section above for a detailed comparative analysis of these options.
957+
943958
# Future possibilities
944959
[future-possibilities]: #future-possibilities
945960

0 commit comments

Comments
 (0)