dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update text/0000-return-type-notation.md 

Co-authored-by: Tyler Mandry <tmandry@gmail.com>
This commit is contained in:
Niko Matsakis 2024-06-18 06:07:30 -04:00 committed by GitHub
parent a9de4555bb
commit 0e86f5591f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
text/0000-return-type-notation.md
View File

@ -959,7 +959,7 @@ Unlike a regular associated type, this RFC does not allow a trait bound that spe
rpjohnst suggested that we may wish to support a syntax like `T: Trait<method(..) -> T>`, perhaps in conjunction with specified argument types. rpjohnst suggested that we may wish to support a syntax like `T: Trait<method(..) -> T>`, perhaps in conjunction with specified argument types.
They further pointed out that permitting `T::method(..)` as a standalone type could be seen as inconsistent, given that `fn foo()` is normally shorthand for `-> ()`. They further pointed out that permitting `T::method(..)` as a standalone type could be seen as inconsistent, given that `fn foo()` is normally shorthand for `-> ()`.
However, *not* supporting `T::method(..)` as a standalone type could also be seen as inconsistent, since normally `T: Trait<Bar: Send>` and `T::Bar: Send` are equivalent. However, *not* supporting `T::method(..)` as a standalone type could also be seen as inconsistent, since normally `T: Trait<Bar: Send>` and `T::Bar: Send` are equivalent.
Prior to stabilizing the "send position" syntax, we should be sure we are comfortable with this. Prior to stabilizing the "associated type position" syntax, we should be sure we are comfortable with this.
# Future possibilities # Future possibilities