mirror of https://github.com/rust-lang/rfcs
Merge pull request #3616 from toofooboo/master
text: fix typos in comments
This commit is contained in:
commit
c62a056871
|
@ -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
|
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
|
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
|
(resp. `IndexMut`) should also provide a `get` method (resp. `get_mut`) as a
|
||||||
non-failing variant that returns an `Option` value.
|
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.
|
be used in a nonblocking "mode" or style.
|
||||||
|
|
||||||
Rather, the hope is that the basic abstractions of files, paths, sockets, and so
|
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
|
with nonblocking APIs. This is the case for most existing languages, which offer
|
||||||
multiple interoperating IO models.
|
multiple interoperating IO models.
|
||||||
|
|
||||||
|
|
|
@ -115,7 +115,7 @@ Here is the Ember RFC section, with appropriate substitutions and modifications:
|
||||||
> # How We Teach This
|
> # 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?
|
> 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?
|
> 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
|
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
|
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
|
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
|
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
|
attribute in the crate. E.g., allowing `#[foo::bar]` to be used (but not
|
||||||
|
|
Loading…
Reference in New Issue