mirror of https://github.com/rust-lang/rfcs
text: fix typos in comments
Signed-off-by: toofooboo <cmaker@foxmail.com>
This commit is contained in:
parent
70c0cc7620
commit
cdf8dd5948
|
@ -1108,7 +1108,7 @@ These traits will be implemented for: `[T]`, `Vec`, `RingBuf`, `HashMap`, `TreeM
|
|||
|
||||
As a general convention, implementation of the `Index` traits will *fail the
|
||||
task* if the index is invalid (out of bounds or key not found); they will
|
||||
therefor return direct references to values. Any collection implementing `Index`
|
||||
therefore return direct references to values. Any collection implementing `Index`
|
||||
(resp. `IndexMut`) should also provide a `get` method (resp. `get_mut`) as a
|
||||
non-failing variant that returns an `Option` value.
|
||||
|
||||
|
|
|
@ -294,7 +294,7 @@ models or nonblocking IO, nor is it a goal for the blocking APIs to eventually
|
|||
be used in a nonblocking "mode" or style.
|
||||
|
||||
Rather, the hope is that the basic abstractions of files, paths, sockets, and so
|
||||
on will eventually be usable directly within an async IO programing model and/or
|
||||
on will eventually be usable directly within an async IO programming model and/or
|
||||
with nonblocking APIs. This is the case for most existing languages, which offer
|
||||
multiple interoperating IO models.
|
||||
|
||||
|
|
|
@ -115,7 +115,7 @@ Here is the Ember RFC section, with appropriate substitutions and modifications:
|
|||
> # How We Teach This
|
||||
> What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Rust patterns, or as a wholly new one?
|
||||
>
|
||||
> Would the acceptance of this proposal change how Rust is taught to new users at any level? What additions or changes to the Rust Reference, _The Rust Programing Language_, and/or _Rust by Example_ does it entail?
|
||||
> Would the acceptance of this proposal change how Rust is taught to new users at any level? What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail?
|
||||
>
|
||||
> How should this feature be introduced and taught to existing Rust users?
|
||||
|
||||
|
|
|
@ -132,7 +132,7 @@ There will be some opt-in mechanism for crates to declare that they want to
|
|||
allow use of a tool's attributes. This might be in the source text (an attribute
|
||||
as in #1755 or new syntax, e.g., `extern attribute foo;`) or passed to rustc as
|
||||
a command line flag (e.g., `--extern-attr foo`). The exact mechanism is
|
||||
deliberately unspecifed.
|
||||
deliberately unspecified.
|
||||
|
||||
After opting-in to `foo`, a crate can use `foo` as the base of a path in any
|
||||
attribute in the crate. E.g., allowing `#[foo::bar]` to be used (but not
|
||||
|
|
Loading…
Reference in New Issue