diff --git a/text/0019-opt-in-builtin-traits.md b/text/0019-opt-in-builtin-traits.md index c29e0356326..fce87d336cc 100644 --- a/text/0019-opt-in-builtin-traits.md +++ b/text/0019-opt-in-builtin-traits.md @@ -80,7 +80,7 @@ people avoid `Cell` and `Rc` when not needed. Explicit opt-in threatens that future, however, because fewer types will implement `Share`, even if they are in fact threadsafe. -With respect to extensibility, it is partiularly worrisome that if a +With respect to extensibility, it is particularly worrisome that if a library forgets to implement `Send` or `Share`, downstream clients are stuck. They cannot, for example, use a newtype wrapper, because it would be illegal to implement `Send` on the newtype. This implies that @@ -123,7 +123,7 @@ makes them *less* built-in, but still requires custom logic in the `Safe` or `Share` are implemented. After the changes I propose, the only traits which would be -specicially understood by the compiler are `Copy` and `Sized`. I +specifically understood by the compiler are `Copy` and `Sized`. I consider this acceptable, since those two traits are intimately tied to the core Rust type system, unlike `Send` and `Share`. @@ -198,7 +198,7 @@ that `T` implements `Foo`. This allows recursive types like struct List { data: T, next: Option> } to be checked successfully. Otherwise, we would recursive infinitely. -(This procedure is directly analagous to what the existing +(This procedure is directly analogous to what the existing `TypeContents` code does.) Note that there exist types that expand to an infinite tree of types. @@ -367,20 +367,20 @@ traits. In effect, opt-in is anti-modular in its own way. To be more specific, imagine that library A wishes to define a `Untainted` trait, and it specifically opts out of `Untainted` for some base set of types. It then wishes to have routines that only -operate on `Untained` data. Now imagine that there is some other +operate on `Untainted` data. Now imagine that there is some other library B that defines a nifty replacement for `Vector`, `NiftyVector`. Finally, some library C wishes to use a `NiftyVector`, which should not be considered tainted, because it doesn't reference any tainted strings. However, `NiftyVector` does not implement `Untainted` (nor can it, without either library A -or libary B knowing about one another). Similar problems arise for any +or library B knowing about one another). Similar problems arise for any trait, of course, due to our coherence rules, but often they can be overcome with new types. Not so with `Send` and `Share`. #### Other use cases Part of the design involves making space for other use cases. I'd like -to skech out how some of those use cases can be implemented briefly. +to sketch out how some of those use cases can be implemented briefly. This is not included in the *Detailed design* section of the RFC because these traits generally concern other features and would be added under RFCs of their own. diff --git a/text/0040-libstd-facade.md b/text/0040-libstd-facade.md index 3ad2d525356..de89671be27 100644 --- a/text/0040-libstd-facade.md +++ b/text/0040-libstd-facade.md @@ -81,7 +81,7 @@ many locations. #### Strings In a post-DST world, the string type will actually be a library-defined type, -`Str` (or similarly named). Strings will no longer be a lanuage feature or a +`Str` (or similarly named). Strings will no longer be a language feature or a language-defined type. This implies that any methods on strings must be in the same crate that defined the `Str` type, or done through extension traits. @@ -383,7 +383,7 @@ various environments seems beneficial. etc. This route has may have the problem of "multiple standard libraries" in that code compatible with the "libc libstd" is not necessarily compatible with the "no libc libstd". Asserting that a crate is compatible with multiple - profiles would involve requiring multiple compliations. + profiles would involve requiring multiple compilations. * Removing libstd entirely. If the standard library is simply a facade, the compiler could theoretically only inject a select number of crates into the diff --git a/text/0048-traits.md b/text/0048-traits.md index 7a1c624993c..8a0b4cc1439 100644 --- a/text/0048-traits.md +++ b/text/0048-traits.md @@ -224,7 +224,7 @@ we find we need more type information to proceed with some type-overloaded operation, rather than reporting an error we can try and resolve pending constraints. If that helps give more information, we can carry on. Once we reach the end of the function, we must then -resolve all pending constriants that have not yet been resolved for +resolve all pending constraints that have not yet been resolved for some other reason. Note that there is some interaction with the distinction between input @@ -527,7 +527,7 @@ slightly modified example: As before, we'll start out with a type of `Monster`, but this type the method `move_to_room()` has a receiver type of `Gc`. This doesn't match cases 1, 2, or 3, so we proceed to case 4 and *unwind* -by one adustment. Since the most recent adjustment was to deref from +by one adjustment. Since the most recent adjustment was to deref from `Gc` to `Monster`, we are left with a type of `Gc`. We now search again. This time, we match case 1. So the final result is `Mob::move_to_room(victim, room)`. This last case is @@ -660,7 +660,7 @@ extent. ## The "resolve" algorithm The basis for the coherence check, method lookup, and vtable lookup -algoritms is the same function, called *RESOLVE*. The basic idea is +algorithms is the same function, called *RESOLVE*. The basic idea is that it takes a set of obligations and tries to resolve them. The result is four sets: diff --git a/text/0049-match-arm-attributes.md b/text/0049-match-arm-attributes.md index 54ed3321828..15dc84ae318 100644 --- a/text/0049-match-arm-attributes.md +++ b/text/0049-match-arm-attributes.md @@ -9,7 +9,7 @@ Allow attributes on match arms. # Motivation One sometimes wishes to annotate the arms of match statements with -attributes, for example with conditional complilation `#[cfg]`s or +attributes, for example with conditional compilation `#[cfg]`s or with branch weights (the latter is the most important use). For the conditional compilation, the work-around is duplicating the diff --git a/text/0068-const-unsafe-pointers.md b/text/0068-const-unsafe-pointers.md index fe6d54ec833..f1c1b37b4e4 100644 --- a/text/0068-const-unsafe-pointers.md +++ b/text/0068-const-unsafe-pointers.md @@ -104,7 +104,7 @@ the language, `const`. * How much can the compiler help out when coercing `&mut T` to `*mut T`? As previously stated, the source pointer `&mut T` is consumed during the - coerction (it's already a linear type), but this can lead to some unexpected + coercion (it's already a linear type), but this can lead to some unexpected results: extern { diff --git a/text/0092-struct-grammar.md b/text/0092-struct-grammar.md index 09c0ca8c5b9..a78d8ad8c34 100644 --- a/text/0092-struct-grammar.md +++ b/text/0092-struct-grammar.md @@ -18,7 +18,7 @@ literals to not require the `:` (e.g., if we allow empty structs to be written with braces, or if we allow struct literals to unify field names to local variable names, as has been suggested in the past and which we currently do for struct literal patterns). We should also be able to give better error messages -today if users make these mistakes. More worringly, we might come up with some +today if users make these mistakes. More worryingly, we might come up with some language feature in the future which is not predictable now and which breaks with the current system. diff --git a/text/0100-partial-cmp.md b/text/0100-partial-cmp.md index 5069559598e..8e059fca72a 100644 --- a/text/0100-partial-cmp.md +++ b/text/0100-partial-cmp.md @@ -4,7 +4,7 @@ # Summary -Add a `partial_cmp` method to `PartialOrd`, analagous to `cmp` in `Ord`. +Add a `partial_cmp` method to `PartialOrd`, analogous to `cmp` in `Ord`. # Motivation @@ -93,7 +93,7 @@ should be. It would also require more work to implement `PartialOrd` once the currently planned `cmp` reform has finished as noted above. `partial_cmp` could just be called `cmp`, but it seems like UFCS would need to -be implemented first for that to be workrable. +be implemented first for that to be workable. # Unresolved questions diff --git a/text/0109-remove-crate-id.md b/text/0109-remove-crate-id.md index 9910df83e72..8cffe8c56a3 100644 --- a/text/0109-remove-crate-id.md +++ b/text/0109-remove-crate-id.md @@ -72,14 +72,14 @@ Note that both the `` and the `` are missing by default. The and the `` was removed to make the output filename predictable. The three original goals can still be satisfied with this simplified naming -scheme. As explained in th enext section, the compiler's "glob pattern" when +scheme. As explained in the next section, the compiler's "glob pattern" when searching for a crate named `foo` will be `libfoo*.rlib`, which will help rationalize some of these conclusions. * Libraries of the same name can exist next to one another because they can be manually renamed to have extra data after the `libfoo`, such as the version. * Libraries of the same name and version, but different source, can also exist - by modifing what comes after `libfoo`, such as including a hash. + by modifying what comes after `libfoo`, such as including a hash. * Rust does not need to occupy a privileged namespace as the default rust installation would include hashes in all the filenames as necessary. More on this later. @@ -148,7 +148,7 @@ not compile a crate with two different versions of an upstream crate. Additionally, cargo could not substitute `libfast-json` for `libslow-json` at compile time (assuming they have the same API). -To accomodate an "expert mode" in rustc, the compiler will grow a new command +To accommodate an "expert mode" in rustc, the compiler will grow a new command line flag of the form: ``` diff --git a/text/0115-rm-integer-fallback.md b/text/0115-rm-integer-fallback.md index 6b526df4c08..9c8ed332a0e 100644 --- a/text/0115-rm-integer-fallback.md +++ b/text/0115-rm-integer-fallback.md @@ -51,7 +51,7 @@ enum Color { Red = 0, Green = 1, Blue = 2 } ``` Currently, an unsuffixed integer defaults to `int`. Instead, we will -only require enum descriminants primitive integers of unspecified +only require enum discriminants primitive integers of unspecified type; assigning an integer to an enum will behave as if casting from from the type of the integer to an unsigned integer with the size of the enum discriminant. diff --git a/text/0130-box-not-special.md b/text/0130-box-not-special.md index 41e08c5b7b7..2a85932f2e9 100644 --- a/text/0130-box-not-special.md +++ b/text/0130-box-not-special.md @@ -12,7 +12,7 @@ Currently the `Box` type is special-cased and converted to the old `~T` internally. This is mostly invisible to the user, but it shows up in some places that give special treatment to `Box`. This RFC is specifically concerned with the fact that the borrow checker has -greater precision when derefencing `Box` vs other smart pointers +greater precision when dereferencing `Box` vs other smart pointers that rely on the `Deref` traits. Unlike the other kinds of special treatment, we do not currently have a plan for how to extend this behavior to all smart pointer types, and hence we would like to remove @@ -103,7 +103,7 @@ treatment of box to other smart pointer types: if the optimization is not performed it affects what programs can successfully type check. (Naturally it is also observable.) -2. Some sort of unsafe deref trait that acknolwedges possibliity of +2. Some sort of unsafe deref trait that acknowledges possibility of other pointers into the referent. Unappealing because the problem is not that bad as to require unsafety. diff --git a/text/0132-ufcs.md b/text/0132-ufcs.md index 686c58e9244..1301615c8ef 100644 --- a/text/0132-ufcs.md +++ b/text/0132-ufcs.md @@ -173,11 +173,11 @@ rejection are listed: module::type::(Trait::member) ::member --> semantics of parentheses considered too subtle - --> cannot accomodate types that are not paths, like `[int]` + --> cannot accommodate types that are not paths, like `[int]` (type: Trait)::member ::member --> complicated to parse - --> cannot accomodate types that are not paths, like `[int]` + --> cannot accommodate types that are not paths, like `[int]` ... (I can't remember all the rest) @@ -209,4 +209,4 @@ to try and change the question: object type and then `ToStr` could be used as syntactic sugar for a type parameter. But there exists a lot of precedent for the current approach and hence I think this is likely a bad idea (not to mention - that it'a a drastic change). + that it's a drastic change). diff --git a/text/0135-where.md b/text/0135-where.md index 24e24529874..da742db9b74 100644 --- a/text/0135-where.md +++ b/text/0135-where.md @@ -444,7 +444,7 @@ This is unfortunately somewhat ambiguous, since a bound like `T:Eq` could either be declared a type parameter `T` or as a condition that the (existing) type `T` implement `Eq`. -**Use a colon intead of the keyword.** There is some precedent for +**Use a colon instead of the keyword.** There is some precedent for this from the type state days. Unfortunately, it doesn't work with traits due to the supertrait list, and it also doesn't look good with the use of `:` as a trait-bound separator: diff --git a/text/0169-use-path-as-id.md b/text/0169-use-path-as-id.md index f0f2313cc3d..862c2baf837 100644 --- a/text/0169-use-path-as-id.md +++ b/text/0169-use-path-as-id.md @@ -44,7 +44,7 @@ mod new_code { There are two benefits we can see by comparing `mod old_code` and `mod new_code`: - * As alluded to above, now all of the imported identfifiers are on + * As alluded to above, now all of the imported identifiers are on the right-hand side of the block of view items. * Additionally, the left-hand side looks much more regular, since one @@ -194,7 +194,7 @@ extern crate old_name as new_name; ``` I have no opinion on whether this should be added or not. Arguably -this choice is orthgonal to the goals of this RFC (since, if this is a +this choice is orthogonal to the goals of this RFC (since, if this is a good idea, it could just as well be implemented with the `=` syntax). Perhaps it should just be filed as a separate RFC on its own. diff --git a/text/0212-restore-int-fallback.md b/text/0212-restore-int-fallback.md index c92747224d4..7bd6f985e37 100644 --- a/text/0212-restore-int-fallback.md +++ b/text/0212-restore-int-fallback.md @@ -125,7 +125,7 @@ the major calling conventions), it's faster than 64-bit integers in arithmetic today, and is superior in memory usage while still providing a reasonable range of possible values. -To expand on the perfomance argument: `i32` obviously uses half of the +To expand on the performance argument: `i32` obviously uses half of the memory of `i64` meaning half the memory bandwidth used, half as much cache consumption and twice as much vectorization – additionally arithmetic (like multiplication and division) is faster on some of the diff --git a/text/0213-defaulted-type-params.md b/text/0213-defaulted-type-params.md index 0e8af7805c0..64191dadfc5 100644 --- a/text/0213-defaulted-type-params.md +++ b/text/0213-defaulted-type-params.md @@ -252,7 +252,7 @@ can only be referenced from within a fn body. ### References to generic impls Users never explicitly "reference" an impl. Rather, the trait matching -system implicitly instantaites impls as part of trait matching. This +system implicitly instantiates impls as part of trait matching. This implies that all type parameters are always instantiated with type variables. These type variables are assigned fallbacks according to the defaults given. diff --git a/text/0235-collections-conventions.md b/text/0235-collections-conventions.md index e922c617860..8a44b60c33e 100644 --- a/text/0235-collections-conventions.md +++ b/text/0235-collections-conventions.md @@ -1367,7 +1367,7 @@ fn partitioned(&self, f: |&T| -> bool) -> (Vec, Vec); These two functions transform a vector/slice into a pair of vectors, based on a "partitioning" function that says which of the two vectors to place elements into. The `partition` variant works by moving elements of the vector, while -`paritioned` clones elements. +`partitioned` clones elements. There are a few unfortunate aspects of an API like this one: diff --git a/text/0243-trait-based-exception-handling.md b/text/0243-trait-based-exception-handling.md index 946428d000f..9c96cf1f6ce 100644 --- a/text/0243-trait-based-exception-handling.md +++ b/text/0243-trait-based-exception-handling.md @@ -122,7 +122,7 @@ associated block. If no exception is thrown, then the result is `Ok(v)` where `v` is the value of the block. Otherwise, if an exception is thrown, then the result is `Err(e)`. Note that unlike other languages, a `catch` block always catches all errors, and they -must all be coercable to a single type, as a `Result` only has a +must all be coercible to a single type, as a `Result` only has a single `Err` type. This dramatically simplifies thinking about the behavior of exception-handling code. @@ -262,7 +262,7 @@ a distinct motivation, and we should evaluate them independently. # Unresolved questions -These questions should be satisfactorally resolved before stabilizing the +These questions should be satisfactorily resolved before stabilizing the relevant features, at the latest. ## Optional `match` sugar diff --git a/text/0339-statically-sized-literals.md b/text/0339-statically-sized-literals.md index 8b370509d67..359a80a9241 100644 --- a/text/0339-statically-sized-literals.md +++ b/text/0339-statically-sized-literals.md @@ -162,7 +162,7 @@ Minor breakage: fn main() { let s = "Hello"; fn f(arg: &str) {} - f(s); // Will require explicit slicing f(s[]) or implicit DST coersion from reference f(&s) + f(s); // Will require explicit slicing f(s[]) or implicit DST coercion from reference f(&s) } ``` diff --git a/text/0344-conventions-galore.md b/text/0344-conventions-galore.md index 615c2ebfd77..5bc8c8b9583 100644 --- a/text/0344-conventions-galore.md +++ b/text/0344-conventions-galore.md @@ -265,7 +265,7 @@ easy to draw the wrong conclusion. This RFC proposes to use a `Prelude` suffix for these basic traits. Since the traits are, in fact, included in the prelude their names do not generally appear in Rust programs. Therefore, choosing a longer and clearer name will help avoid -confusion about the intent of these traits, and will avoid namespace polution. +confusion about the intent of these traits, and will avoid namespace pollution. (There is one important drawback in today's Rust: associated functions in these traits cannot yet be called directly on the types implementing the traits. These diff --git a/text/0369-num-reform.md b/text/0369-num-reform.md index 14e56c19ec4..e3d89dae6c4 100644 --- a/text/0369-num-reform.md +++ b/text/0369-num-reform.md @@ -6,7 +6,7 @@ This RFC is preparation for API stabilization for the `std::num` module. The proposal is to finish the simplification efforts started in -[@bjz's reversal of the numerics hierarcy](https://github.com/rust-lang/rust/issues/10387). +[@bjz's reversal of the numerics hierarchy](https://github.com/rust-lang/rust/issues/10387). Broadly, the proposal is to collapse the remaining numeric hierarchy in `std::num`, and to provide only limited support for generic @@ -45,7 +45,7 @@ building such a hierarchy within `libstd` was misguided: The `std::num` module has thus been slowly migrating *away* from a large trait hierarchy toward a simpler one providing just APIs for primitive data types: this is -[@bjz's reversal of the numerics hierarcy](https://github.com/rust-lang/rust/issues/10387). +[@bjz's reversal of the numerics hierarchy](https://github.com/rust-lang/rust/issues/10387). Along side this effort, there are already external numerics packages like [@bjz's num-rs](https://github.com/bjz/num-rs). @@ -233,7 +233,7 @@ pub trait Int: Copy + Clone + PartialOrd + PartialEq // Deprecated: // fn is_zero(&self) -> bool; - // Bit twidling + // Bit twiddling fn count_ones(self) -> uint; fn count_zeros(self) -> uint { ... } fn leading_zeros(self) -> uint; diff --git a/text/0380-stabilize-std-fmt.md b/text/0380-stabilize-std-fmt.md index 65c048954be..b379225129f 100644 --- a/text/0380-stabilize-std-fmt.md +++ b/text/0380-stabilize-std-fmt.md @@ -224,7 +224,7 @@ some form of "write error" happened, but conveys no extra information. This API has a number of oddities: * The type `Formatter` has inherent `write` and `write_fmt` methods to be used - in conjuction with the `write!` macro return an instance of `fmt::Result`. + in conjunction with the `write!` macro return an instance of `fmt::Result`. * The `Formatter` type also implements the `std::io::Writer` trait in order to be able to pass around a `&mut Writer`. * This relies on the duck-typing of macros and for the inherent `write_fmt` diff --git a/text/0385-module-system-cleanup.md b/text/0385-module-system-cleanup.md index 875c0780e14..3c610741584 100644 --- a/text/0385-module-system-cleanup.md +++ b/text/0385-module-system-cleanup.md @@ -90,7 +90,7 @@ mod foo { ``` -While its generally not neccessary to export a extern library directly, the need for it does arise +While its generally not necessary to export a extern library directly, the need for it does arise occasionally during refactorings of huge crate collections, generally if a public module gets turned into its own crate. diff --git a/text/0390-enum-namespacing.md b/text/0390-enum-namespacing.md index c24a10a92ad..68619b8b502 100644 --- a/text/0390-enum-namespacing.md +++ b/text/0390-enum-namespacing.md @@ -245,7 +245,7 @@ bootstrapping. After a new stage 0 snapshot, the standard library will be ported and resolve will be updated to remove variant definitions in the flat namespace. This will happen as one atomic PR to keep the implementation phase as compressed as -possible. In addition, if unforseen problems arise during this set of work, we +possible. In addition, if unforeseen problems arise during this set of work, we can roll back the initial commit and put the change off until after 1.0, with only a small pre-1.0 change required. This initial conversion will focus on making the minimal set of changes required to port the compiler and standard @@ -306,7 +306,7 @@ decidedly worse than not having to worry about fallback at all. Earlier iterations of namespaced enum proposals suggested preserving flat enums and adding `enum mod` syntax for namespaced enums. However, variant namespacing -isn't a large enough enough difference for the additon of a second way to +isn't a large enough enough difference for the addition of a second way to define enums to hold its own weight as a language feature. In addition, it would simply cause confusion, as library authors need to decide which one they want to use, and library consumers need to double check which place they can diff --git a/text/0403-cargo-build-command.md b/text/0403-cargo-build-command.md index cb169b59346..c4a783f08f3 100644 --- a/text/0403-cargo-build-command.md +++ b/text/0403-cargo-build-command.md @@ -167,7 +167,7 @@ It is illegal to define `links` without also defining `build`. A number of native dependencies have various dependencies depending on what platform they're building for. For example, libcurl does not depend on OpenSSL on Windows, but it is a common dependency on unix-based systems. To this end, -Cargo will gain support for platform-specific dependencies, solving constriant 7 +Cargo will gain support for platform-specific dependencies, solving constraint 7 above: ```toml @@ -258,7 +258,7 @@ separate set of dependencies solves a number of constraints: * When cross-compiling, the build tool as well as all of its dependencies are required to be built for the host architecture instead of the target - architecture. A clear deliniation will indicate precisely what dependencies + architecture. A clear delineation will indicate precisely what dependencies need to be built for the host architecture. * Common packages, such as one to build `cmake`-based dependencies, can develop conventions around filesystem hierarchy formats to require minimum diff --git a/text/0503-prelude-stabilization.md b/text/0503-prelude-stabilization.md index 411a9ddd86a..8e3a4d14c83 100644 --- a/text/0503-prelude-stabilization.md +++ b/text/0503-prelude-stabilization.md @@ -61,7 +61,7 @@ pub use clone::Clone; // for the inclusion of these traits in the prelude. pub use cmp::{PartialEq, PartialOrd, Eq, Ord}; -// Iterators are one of the most core primitives in the standard libary which is +// Iterators are one of the most core primitives in the standard library which is // used to interoperate between any sort of sequence of data. Due to the // widespread use, these traits and extension traits are all present in the // prelude. @@ -291,7 +291,7 @@ an open question by this RFC. A fairly large amount of functionality was removed from the prelude in order to hone in on the driving goals of the prelude, but this unfortunately means that many imports must be added throughout code currently using these reexports. It -is expected, however, that the most painful removals will have roughtly equal +is expected, however, that the most painful removals will have roughly equal ergonomic replacements in the future. For example: * Removal of `Path` and friends will retain the current level of ergonomics with @@ -316,7 +316,7 @@ largely be filled with various permutations of moving reexports between the This RFC is fairly aggressive about removing functionality from the prelude, but is unclear how necessary this is. If Rust grows the ability to -backwards-compatibly modify the prelude in some fasion (for example introducing +backwards-compatibly modify the prelude in some fashion (for example introducing multiple preludes that can be opted into) then the aggressive removal may not be necessary. diff --git a/text/0507-release-channels.md b/text/0507-release-channels.md index b1a89071a6e..a0958cfd670 100644 --- a/text/0507-release-channels.md +++ b/text/0507-release-channels.md @@ -184,7 +184,7 @@ globs and `macro_rules!` imports become stable. ## Merging stability attributes and feature gates -In addition to the feature gates that, in conjuction with the +In addition to the feature gates that, in conjunction with the aforementioned `unstable_features` lint, manage the stable evolution of *language* features, Rust *additionally* has another independent system for managing the evolution of *library* features, 'stability @@ -342,7 +342,7 @@ the minimum required Rust language version required to compile a crate. Currently the Rust language version coincides with the version of the `rustc` compiler. -In the absense of user-supplied information about minimum language +In the absence of user-supplied information about minimum language version requirements, *Cargo will attempt to use feature information to determine version compatibility*: by knowing in which version each feature of the language and each feature of the library was @@ -351,7 +351,7 @@ determine the minimum version required; and rustc may assume that the crate will be compatible with future stable releases. There are two caveats: first, conditional compilation makes it not possible in some cases to detect all features in use, which may result in Cargo -detecting a minumum version less than that required on all +detecting a minimum version less than that required on all platforms. For this and other reasons Cargo will allow the minimum version to be specified manually. Second, rustc can not make any assumptions about compatibility across major revisions of the diff --git a/text/0528-string-patterns.md b/text/0528-string-patterns.md index 360bc318428..0fd372fda0a 100644 --- a/text/0528-string-patterns.md +++ b/text/0528-string-patterns.md @@ -138,9 +138,9 @@ pub trait DoubleEndedSearcher<'a>: ReverseSearcher<'a> {} ``` The basic idea of a `Searcher` is to expose a interface for -iterating through all connected string fragments of the haystack while classifing them as either a match, or a reject. +iterating through all connected string fragments of the haystack while classifying them as either a match, or a reject. -This happens in form of the returned enum value. A `Match` needs to contain the start and end indices of a complete non-overlapping match, while a `Rejects` may be emitted for arbitary non-overlapping rejected parts of the string, as long as the start and end indices lie on valid utf8 boundaries. +This happens in form of the returned enum value. A `Match` needs to contain the start and end indices of a complete non-overlapping match, while a `Rejects` may be emitted for arbitrary non-overlapping rejected parts of the string, as long as the start and end indices lie on valid utf8 boundaries. Similar to iterators, depending on the concrete implementation a searcher can have additional capabilities that build on each other, which is why they will be diff --git a/text/0546-Self-not-sized-by-default.md b/text/0546-Self-not-sized-by-default.md index fb08caecc2a..9a908a8fadd 100644 --- a/text/0546-Self-not-sized-by-default.md +++ b/text/0546-Self-not-sized-by-default.md @@ -54,7 +54,7 @@ sense to inherit, since all that the `?Sized` notation is saying is "do not add `Sized`", and you can't inherit the absence of a thing. Having traits simply not inherit from `Sized` by default sidesteps this problem altogether and avoids the need for a special -syntax to supress the (now absent) default. +syntax to suppress the (now absent) default. Removing the default also has the benefit of making traits applicable to more types by default. One particularly useful case is trait diff --git a/text/0550-macro-future-proofing.md b/text/0550-macro-future-proofing.md index 3cec600ab8c..d0c548964ef 100644 --- a/text/0550-macro-future-proofing.md +++ b/text/0550-macro-future-proofing.md @@ -440,7 +440,7 @@ why particular matchers are legal and others are not. * `( $($a:tt $b:tt)* ; )` : legal, because FIRST(`$b:tt`) = { `$b:tt` } is ⊆ FOLLOW(`tt`) = ANYTOKEN, as is FIRST(`;`) = { `;` }. - * `( $($t:tt),* , $(t:tt),* )` : legal (though any attempt to actually use this macro will signal a local ambguity error during expansion). + * `( $($t:tt),* , $(t:tt),* )` : legal (though any attempt to actually use this macro will signal a local ambiguity error during expansion). * `($ty:ty $(; not sep)* -)` : illegal, because FIRST(`$(; not sep)* -`) = { `;`, `-` } is not in FOLLOW(`ty`). @@ -479,7 +479,7 @@ reasonable freedom and can be extended in the future. * replaced detailed design with a specification-oriented presentation rather than an implementation-oriented algorithm. * fixed some oversights in the specification that led to matchers like `$e:expr { stuff }` being accepted (which match fragments like `break { stuff }`, significantly limiting future language extensions), * expanded the follows sets for `ty` to include `OpenDelim(Brace), Ident(where), Or` (since Rust's grammar already requires all of `|foo:TY| {}`, `fn foo() -> TY {}` and `fn foo() -> TY where {}` to work). - * expanded the follow set for `pat` to include `Or` (since Rust's grammar already requires `match (true,false) { PAT | PAT => {} }` and `|PAT| {}` to work); see also [RFC issue 1336][]. Also added `If` and `In` to follow set for `pat` (to make the specifiation match the old implementation). + * expanded the follow set for `pat` to include `Or` (since Rust's grammar already requires `match (true,false) { PAT | PAT => {} }` and `|PAT| {}` to work); see also [RFC issue 1336][]. Also added `If` and `In` to follow set for `pat` (to make the specification match the old implementation). [RFC issue 1336]: https://github.com/rust-lang/rfcs/issues/1336 diff --git a/text/0556-raw-lifetime.md b/text/0556-raw-lifetime.md index ce1c9d36868..b60ae194e88 100644 --- a/text/0556-raw-lifetime.md +++ b/text/0556-raw-lifetime.md @@ -19,7 +19,7 @@ flexibility of inferring the lifetime from the usage, while falling short of providing useful safety semantics in exchange. A typical case where the lifetime needs to be adjusted is in bindings -to a foregn library, when returning a reference to an object's +to a foreign library, when returning a reference to an object's inner value (we know from the library's API contract that the inner data's lifetime is bound to the containing object): ```rust diff --git a/text/0558-require-parentheses-for-chained-comparisons.md b/text/0558-require-parentheses-for-chained-comparisons.md index 3651d2e248d..47c46d6198b 100644 --- a/text/0558-require-parentheses-for-chained-comparisons.md +++ b/text/0558-require-parentheses-for-chained-comparisons.md @@ -19,7 +19,7 @@ This code is currently accepted and is evaluated as `((a == b) == c)`. This may be confusing to programmers coming from languages like Python, where chained comparison operators are evaluated as `(a == b && b == c)`. -In C, the same problem exists (and is excerbated by implicit conversions). +In C, the same problem exists (and is exacerbated by implicit conversions). Styleguides like Misra-C require the use of parentheses in this case. By requiring the use of parentheses, we avoid potential confusion now, diff --git a/text/0560-integer-overflow.md b/text/0560-integer-overflow.md index 2665be58c79..b46e3a535e6 100644 --- a/text/0560-integer-overflow.md +++ b/text/0560-integer-overflow.md @@ -94,7 +94,7 @@ conditions (detailed below). Typically these error conditions correspond to under/overflow but not exclusively. It is the programmers responsibility to avoid these error conditions: any failure to do so can be considered a bug, and hence can be flagged by -a static/dynamic analysis tools as an error. This is largerly a +a static/dynamic analysis tools as an error. This is largely a semantic distinction, though. The result of an error condition depends upon the state of overflow @@ -166,7 +166,7 @@ they be skipped entirely, however. The precise details of how panics may be deferred -- and the definition of a pure operation -- can be hammered out over time, but the intention here is that, at minimum, overflow checks for adjacent numeric operations like `a+b-c` can be -coallesced into a single check. Another useful example might be that, +coalesced into a single check. Another useful example might be that, when summing a vector, the final overflow check could be deferred until the summation is complete. @@ -381,7 +381,7 @@ Illustration of use: If we adopted a model of overflow checks, one could use an explicit request to turn overflow checks *off* as a signal that wrapping is -desirted. This would allow us to do without the `WrappingOps` trait +desired. This would allow us to do without the `WrappingOps` trait and to avoid having unspecified results. See: * [Daniel Micay on June 24][DM24_2] diff --git a/text/0565-show-string-guidelines.md b/text/0565-show-string-guidelines.md index aab154cd721..4e1e869d5d1 100644 --- a/text/0565-show-string-guidelines.md +++ b/text/0565-show-string-guidelines.md @@ -129,7 +129,7 @@ There are two main reasons for this choice: [more direct convenience](https://github.com/SimonSapin/rust-std-candidates#the-show-debugging-macro). * When creating tailored string output via interpolation, the expected "default" - formatting for things like strings is unquoted and unescapted. It would be + formatting for things like strings is unquoted and unescaped. It would be surprising if the default specifiers below did not yield `"hello, world!" as the output string. diff --git a/text/0572-rustc-attribute.md b/text/0572-rustc-attribute.md index 43555f2d0ba..a861b322e85 100644 --- a/text/0572-rustc-attribute.md +++ b/text/0572-rustc-attribute.md @@ -46,4 +46,4 @@ This has the drawback that the attribute parsing and representation will need to Which proposal to use — disallowing `#[rustc_*]` and `#[rustc]` attributes, or just `#[forbid(unused_attribute)]`ing everything. -The name of the feature gate could peraps be improved. \ No newline at end of file +The name of the feature gate could perhaps be improved. diff --git a/text/0587-fn-return-should-be-an-associated-type.md b/text/0587-fn-return-should-be-an-associated-type.md index faf367974d6..fe2a01dad80 100644 --- a/text/0587-fn-return-should-be-an-associated-type.md +++ b/text/0587-fn-return-should-be-an-associated-type.md @@ -126,7 +126,7 @@ impl Iterator for Map, ``` Note that this final option is not legal without this change, because -the type parameter `B` on the impl woudl be unconstrained. +the type parameter `B` on the impl would be unconstrained. # Drawbacks diff --git a/text/0735-allow-inherent-impls-anywhere.md b/text/0735-allow-inherent-impls-anywhere.md index 8d700157884..416141bab2f 100644 --- a/text/0735-allow-inherent-impls-anywhere.md +++ b/text/0735-allow-inherent-impls-anywhere.md @@ -13,7 +13,7 @@ The main motivation for disallowing such `impl` bodies was the implementation detail of fake modules being created to allow resolving `Type::method`, which only worked correctly for `impl Type {...}` if a `struct Type` or `enum Type` were defined in the same module. The old mechanism was obsoleted by UFCS, -which desugars `Type::method` to `::method` and perfoms a type-based +which desugars `Type::method` to `::method` and performs a type-based method lookup instead, with path resolution having no knowledge of inherent `impl`s - and all of that was implemented by [rust-lang/rust#22172](https://github.com/rust-lang/rust/pull/22172). @@ -64,7 +64,7 @@ could arguably be worse. *Technically*, I am not aware of any formulation that limits inherent methods to user-defined types in the same crate, and this extra support could turn out - to have a straight-foward implementation with no complications, but I'm trying + to have a straight-forward implementation with no complications, but I'm trying to present the whole situation to avoid issues in the future - even though I'm not aware of backwards compatibility ones or any related to compiler internals. diff --git a/text/0769-sound-generic-drop.md b/text/0769-sound-generic-drop.md index ad43561b151..734db1f291e 100644 --- a/text/0769-sound-generic-drop.md +++ b/text/0769-sound-generic-drop.md @@ -184,7 +184,7 @@ expressing the constraint that one lifetime be strictly greater than another lifetime or type (the form `'a:'b` only formally says that `'a` must live *at least* as long as `'b`). -Thus, client code like that in `unwary_client` can inadvertantly set +Thus, client code like that in `unwary_client` can inadvertently set up scenarios where Sylvester's code may break, and Sylvester might be completely unaware of the vulnerability. diff --git a/text/0809-box-and-in-for-stdlib.md b/text/0809-box-and-in-for-stdlib.md index 406b04f4018..ca6d2ded378 100644 --- a/text/0809-box-and-in-for-stdlib.md +++ b/text/0809-box-and-in-for-stdlib.md @@ -124,13 +124,13 @@ tandem with types provided by the stdlib, such as `Box`. [RFC 92]: https://github.com/rust-lang/rfcs/blob/master/text/0092-struct-grammar.md -* The only stablized implementation for the `box ` operator +* The only stabilized implementation for the `box ` operator proposed by this RFC is `Box`. The question of which other types should support integration with `box ` is a library design issue and needs to go through the conventions and library stabilization process. - Similarly, this RFC does not propose *any* stablized implementation + Similarly, this RFC does not propose *any* stabilized implementation for the `in { }` operator. (An obvious candidate for `in { }` integration would be a `Vec::emplace_back` method; but again, the choice of which such methods to add is a diff --git a/text/0832-from-elem-with-love.md b/text/0832-from-elem-with-love.md index 8d9558efb09..bef9ad77f2f 100644 --- a/text/0832-from-elem-with-love.md +++ b/text/0832-from-elem-with-love.md @@ -52,7 +52,7 @@ let vec = Vec::from_elem(elem, n) * `#4` and `#5` are considered verbose and noisy. They also need to clone one more time than other methods *strictly* need to. -However the issues for `#2` are *entirely* artifical. It's simply a side-effect of +However the issues for `#2` are *entirely* artificial. It's simply a side-effect of forwarding the impl to the identical array syntax. We can just make the code in the `vec!` macro better. This naturally extends the compile-timey `[x; n]` array sugar to the more runtimey semantics of Vec, without introducing "another way to do it". diff --git a/text/0839-embrace-extend-extinguish.md b/text/0839-embrace-extend-extinguish.md index a23acffebf5..275d1e6579d 100644 --- a/text/0839-embrace-extend-extinguish.md +++ b/text/0839-embrace-extend-extinguish.md @@ -84,7 +84,7 @@ not always be sufficient to determine the type of a `vec![]`. ## The Cloneian Candidate -This proposal is artifically restricting itself to `Copy` rather than full +This proposal is artificially restricting itself to `Copy` rather than full `Clone` as a concession to the general Rustic philosophy of Clones being explicit. Since this proposal is largely motivated by simple shuffling of primitives, this is sufficient. Also, because `Copy: Clone`, it would be diff --git a/text/0909-move-thread-local-to-std-thread.md b/text/0909-move-thread-local-to-std-thread.md index 211cfa7bd53..82b24e900d9 100644 --- a/text/0909-move-thread-local-to-std-thread.md +++ b/text/0909-move-thread-local-to-std-thread.md @@ -13,7 +13,7 @@ remove `std::thread_local` from the standard library. Thread locals are directly related to threading. Combining the modules would reduce the number of top level modules, combine related concepts, and make browsing the docs easier. It also would have the potential to -slightly reduce the number of `use` statementsl +slightly reduce the number of `use` statements. # Detailed design diff --git a/text/0911-const-fn.md b/text/0911-const-fn.md index 388d6213c14..744d67fdd16 100644 --- a/text/0911-const-fn.md +++ b/text/0911-const-fn.md @@ -36,7 +36,7 @@ all the fields of `std::thread_local::imp::Key` are public, so they can be filled in by a macro - and they're also marked "stable" (due to the lack of stability hygiene in macros). -A pre-RFC for the removal of the dangerous (and oftenly misued) `static mut` +A pre-RFC for the removal of the dangerous (and often misused) `static mut` received positive feedback, but only under the condition that abstractions could be created and used in `const` and `static` items. @@ -110,7 +110,7 @@ casts, field accesses/indexing, capture-less closures, references and blocks this is not transitive, allowing the (perfectly harmless) creation of, e.g. `None::>` (as an aside, this rule could be used to allow `[x; N]` even for non-`Copy` types of `x`, but that is out of the scope of this RFC) -* references are trully immutable, no value with interior mutability can be placed +* references are truly immutable, no value with interior mutability can be placed behind a reference, and mutable references can only be created from zero-sized values (e.g. `&mut || {}`) - this allows a reference to be represented just by its value, with no guarantees for the actual address in memory diff --git a/text/0968-closure-return-type-syntax.md b/text/0968-closure-return-type-syntax.md index 86679f6cc54..8e5b9a16c1b 100644 --- a/text/0968-closure-return-type-syntax.md +++ b/text/0968-closure-return-type-syntax.md @@ -38,7 +38,7 @@ annotations are very rarely used. # Alternatives I am not aware of any alternate designs. One possibility would be to -remove return type anotations altogether, perhaps relying on type +remove return type annotations altogether, perhaps relying on type ascription or other annotations to force the inferencer to figure things out, but they are useful in rare scenarios. In particular type ascription would not be able to handle a higher-ranked signature like diff --git a/text/0982-dst-coercion.md b/text/0982-dst-coercion.md index 98d32fadeb5..e7a219dec9f 100644 --- a/text/0982-dst-coercion.md +++ b/text/0982-dst-coercion.md @@ -159,13 +159,13 @@ Not as flexible as the previous proposal. The original [DST5 proposal](http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/) contains a similar proposal with no opt-in trait, i.e., coercions are completely -automatic and arbitrarily deep. This is a little too magical and unpredicatable. +automatic and arbitrarily deep. This is a little too magical and unpredictable. It violates some 'soft abstraction boundaries' by interefering with the deep structure of objects, sometimes even automatically (and implicitly) allocating. [RFC 401](https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md) proposed a scheme for proposals where users write their own coercion using -intrinsics. Although more flexible, this allows for implcicit excecution of +intrinsics. Although more flexible, this allows for implicit execution of arbitrary code. If we need the increased flexibility, I believe we can add a manual option to the `CoerceUnsized` trait backwards compatibly. diff --git a/text/1023-rebalancing-coherence.md b/text/1023-rebalancing-coherence.md index fc3ff424fe2..ba1cc8e9532 100644 --- a/text/1023-rebalancing-coherence.md +++ b/text/1023-rebalancing-coherence.md @@ -80,7 +80,7 @@ after the 1.0 release. When you first define a trait, you must also decide whether that trait should have (a) a blanket impls for all `T` and (b) any blanket impls over references. These blanket impls cannot be added later without a -major vesion bump, for fear of breaking downstream clients. +major version bump, for fear of breaking downstream clients. Here are some examples of the kinds of blanket impls that must be added right away: diff --git a/text/1044-io-fs-2.1.md b/text/1044-io-fs-2.1.md index dae56e62d6d..17a1eea9981 100644 --- a/text/1044-io-fs-2.1.md +++ b/text/1044-io-fs-2.1.md @@ -241,7 +241,7 @@ One of the major goals of the `os::unix::fs` design is to enable as much functionality as possible when programming against "unix in general" while still allowing applications to choose to only program against macos, for example. -#### Fate of `Metadata::{accesed, modified}` +#### Fate of `Metadata::{accessed, modified}` At this time there is no suitable type in the standard library to represent the return type of these two functions. The type would either have to be some form @@ -263,7 +263,7 @@ methods will be re-instated as returning that type. Currently there is no stable method of inspecting the permission bits on a file, and it is unclear whether the current unstable methods of doing so, `PermissionsExt::mode`, should be stabilized. The main question around this -piece of functionality is whether to provide a higher level abstractiong (e.g. +piece of functionality is whether to provide a higher level abstraction (e.g. similar to the `bitflags` crate) for the permission bits on unix. This RFC proposes considering the methods for stabilization as-is and not diff --git a/text/1066-safe-mem-forget.md b/text/1066-safe-mem-forget.md index 42263db8b60..8c8ac79ad7c 100644 --- a/text/1066-safe-mem-forget.md +++ b/text/1066-safe-mem-forget.md @@ -108,7 +108,7 @@ of it. This marker trait could work similarly to `Send` where all types are considered leakable by default, but types could opt-out of `Leak`. This approach, however, requires `Rc` and `Arc` to have a `Leak` bound on their type parameter which can often leak unfortunately into many generic contexts (e.g. -trait objects). Another option would be to treak `Leak` more similarly to +trait objects). Another option would be to treat `Leak` more similarly to `Sized` where all type parameters have a `Leak` bound by default. This change may also cause confusion, however, by being unnecessarily restrictive (e.g. all collections may want to take `T: ?Leak`). diff --git a/text/1096-remove-static-assert.md b/text/1096-remove-static-assert.md index ae10ccc7793..2086bac88e6 100644 --- a/text/1096-remove-static-assert.md +++ b/text/1096-remove-static-assert.md @@ -14,15 +14,15 @@ To recap, `static_assert` looks like this: ```rust #![feature(static_assert)] #[static_assert] -static asssertion: bool = true; +static assertion: bool = true; ``` If `assertion` is `false` instead, this fails to compile: ```text error: static assertion failed -static asssertion: bool = false; - ^~~~~ +static assertion: bool = false; + ^~~~~ ``` If you don’t have the `feature` flag, you get another interesting error: diff --git a/text/1105-api-evolution.md b/text/1105-api-evolution.md index b54b66f1d73..5ccd16f934a 100644 --- a/text/1105-api-evolution.md +++ b/text/1105-api-evolution.md @@ -729,7 +729,7 @@ by adding a single explicit, shadowing import. **Default type parameters** Some of the minor changes for moving to more generic code depends on an -interplay between defaulted type paramters and type inference, which has been +interplay between defaulted type parameters and type inference, which has been [accepted as an RFC](https://github.com/rust-lang/rfcs/pull/213) but not yet implemented. @@ -754,7 +754,7 @@ Also known as "optional arguments" -- an arguments to a function to be optional makes it possible to add new arguments after the fact without a major version bump. -**Open-ended explicit type paramters** +**Open-ended explicit type parameters** One hazard is that with today's explicit type parameter syntax, you must always specify *all* type parameters: `foo::(x, y)`. That means that adding a new