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

fix typos

This commit is contained in:
Guanqun Lu 2019-09-12 16:27:09 +08:00
parent 53842bde4c
commit 6331e4c15b
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
text/1522-conservative-impl-trait.md
View File

@ -322,7 +322,7 @@ across abstraction barriers and provide information about a type without the
type's author having to explicitly opt in.
This means, however, that it has to be considered a silent breaking change to
change a function with a abstract return type in a way that removes OIBIT impls,
change a function with an abstract return type in a way that removes OIBIT impls,
which might be a problem. (As noted above, this is already the case for `struct`
definitions.)
@ -344,7 +344,7 @@ use something like a newtype.
### Anonymity
A abstract return type cannot be named in this proposal, which means that it
An abstract return type cannot be named in this proposal, which means that it
cannot be placed into `structs` and so on. This is not a fundamental limitation
in any sense; the limitation is there both to keep this RFC simple, and because
the precise way we might want to allow naming of such types is still a bit
@ -487,7 +487,7 @@ and the compatibility of the current compiler with it is unknown,
it is not yet possible to reach a concrete solution here.
In addition to that, there are also different proposals as to whether
a abstract return type is its own thing or sugar for a associated type,
an abstract return type is its own thing or sugar for a associated type,
how it interacts with other associated items and so on,
so forbidding them in traits seems like the best initial course of action.