@@ -322,7 +322,7 @@ across abstraction barriers and provide information about a type without the
322
322
type's author having to explicitly opt in.
323
323
324
324
This means, however, that it has to be considered a silent breaking change to
325
- change a function with a abstract return type in a way that removes OIBIT impls,
325
+ change a function with an abstract return type in a way that removes OIBIT impls,
326
326
which might be a problem. (As noted above, this is already the case for ` struct `
327
327
definitions.)
328
328
@@ -344,7 +344,7 @@ use something like a newtype.
344
344
345
345
### Anonymity
346
346
347
- A abstract return type cannot be named in this proposal, which means that it
347
+ An abstract return type cannot be named in this proposal, which means that it
348
348
cannot be placed into ` structs ` and so on. This is not a fundamental limitation
349
349
in any sense; the limitation is there both to keep this RFC simple, and because
350
350
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,
487
487
it is not yet possible to reach a concrete solution here .
488
488
489
489
In addition to that , there are also different proposals as to whether
490
- a abstract return type is its own thing or sugar for a associated type ,
490
+ an abstract return type is its own thing or sugar for a associated type ,
491
491
how it interacts with other associated items and so on ,
492
492
so forbidding them in traits seems like the best initial course of action .
493
493
0 commit comments