Fix Typos across apple/swift-evolution repo (#1157)

* Fix Typos

Author: Yogi

index.js

@@ -638,7 +638,7 @@ function toggleFiltering () {
 }
 
 /**
- * Expands or constracts the filter panel, which contains buttons that
+ * Expands or contracts the filter panel, which contains buttons that
  * let users filter proposals based on their current stage in the
  * Swift Evolution process.
  */

proposals/0018-flexible-memberwise-initialization.md

@@ -230,7 +230,7 @@ The changes described in this proposal are *almost* entirely additive.  The only
 
 1. If the implicitly synthesized memberwise initializer was only used *within* the same source file no change is necessary.  An implicit `private` memberwise initializer will still be synthesized by the compiler.
 2. A mechanical migration could generate the explicit code necessary to declare the previously implicit initializer.  This would be an `internal` memberwise initializer with *explicit* parameters used to manually initialize the stored properties with `private` setters.
-3. If the "Access control for init" enhancement were accepted the `private` members could have their access control modified to `private internal(init)` which would allow the implict memberwise intializer to continue to have `internal` visibility as all stored properties would be eligible for parameter synthesis by an `internal` memberwise initializer.
+3. If the "Access control for init" enhancement were accepted the `private` members could have their access control modified to `private internal(init)` which would allow the implicit memberwise intializer to continue to have `internal` visibility as all stored properties would be eligible for parameter synthesis by an `internal` memberwise initializer.
 
 The only other impact on existing code is that memberwise parameters corresponding to `var` properties with initial values will now have default values.  This will be a change in the behavior of the implicit memberwise initializer but will not break any code.  The change will simply allow new code to use that initializer without providing an argument for such parameters.
 
@@ -325,7 +325,7 @@ struct S {
 
 ### Access control for init
 
-In some cases it may be desirable to be able to specify distinct access control for memberwise initialization when using the *automatic* model, for example if that model *almost* has the desired behavior, but the initialization visibiltiy of one property must be adjusted to produce the necessary result.
+In some cases it may be desirable to be able to specify distinct access control for memberwise initialization when using the *automatic* model, for example if that model *almost* has the desired behavior, but the initialization visibility of one property must be adjusted to produce the necessary result.
 
 The syntax used would be identical to that used for specifying distinct access control for a setter.  This feature would likely have its greatest utility in allowing more-private members to participate in more-public memberwise initializers.  It may also be used to inhibit memberwise initialization for some members, although that use would usually be discouraged if the `@nomemberwise` proposal were also accepted.
 

proposals/0024-optional-value-setter.md

@@ -15,7 +15,7 @@ Swift-evolution thread: [link to the discussion thread for that proposal](https:
 
 ## Motivation
 
-In certain cases the `??` operation doesn't help with lengthly variable names, i.e., `really.long.lvalue[expression] = really.long.lvalue[expression] ?? ""`. In addtition to this other languages such as Ruby contain a pipe operator `really.long.lvalue[expression] ||= ""` which works the same way and which is very popular. This lowers the barrier of entry for programmers from that language.
+In certain cases the `??` operation doesn't help with lengthy variable names, i.e., `really.long.lvalue[expression] = really.long.lvalue[expression] ?? ""`. In addtition to this other languages such as Ruby contain a pipe operator `really.long.lvalue[expression] ||= ""` which works the same way and which is very popular. This lowers the barrier of entry for programmers from that language.
 
 In the interest in conciseness and clarity I feel this would be a great addition to swift and would bring the length of that previous statement from
 

proposals/0026-abstract-classes-and-methods.md

@@ -38,7 +38,7 @@ class RESTClient {
     var timeout = 3000
 
     var url : String {
-        assert(false,"Must be overriden")
+        assert(false,"Must be overridden")
         return ""
     }
 

proposals/0063-swiftpm-system-module-search-paths.md

@@ -133,7 +133,7 @@ parameters, they can be added on a per enum basis.
 
 #### Install-names are not standard
 
-`apt` is used across multiple distirbutions and the install-names for
+`apt` is used across multiple distributions and the install-names for
 tools vary. Even for the same distribution install-names may vary
 across releases (eg. from Ubuntu 15.04 to Ubuntu 15.10) or even on
 occasion at finer granularity.

proposals/0067-floating-point-protocols.md

@@ -19,7 +19,7 @@ for generic programming with the most commonly used types.
 Revision 2 reintroduces some of the details of the `Arithmetic` protocol from
 earlier drafts of this proposal, but as methods in the `FloatingPoint` API,
 with the goal of reducing the number of overloads for basic operations.  This
-change was requested by some members of the core langauge team.
+change was requested by some members of the core language team.
 
 Revision 2 also incorporates a number of suggestions from the review list and
 corrects some typos; thanks especially to Xiaodi Wu for thoughtful feedback.

proposals/0085-package-manager-command-name.md

@@ -37,7 +37,7 @@ these are not really flags modifying a build, and should be full commands in the
 
 The intent of this proposal is to establish a forward-looking syntax for supporting
 the full range of future package manager functionality in a clean, expressive, and
-clear manner, without using command-line flags (which should be modifiers on a commmand)
+clear manner, without using command-line flags (which should be modifiers on a command)
 to express commands.
 
 ## Proposed solution

proposals/0088-libdispatch-for-swift3.md

@@ -144,7 +144,7 @@ queue.setSpecific(key: akey, value: 42)
 
 #### Work Items
 
-The existing ```dispatch_block_*``` API group exposes functionality that produces ```dispatch_block_t``` blocks that are wrapped with additional metadata. That behaviour in C has multiple cases where this API group can be accidentally misused because the C types are ambiguously overloaded. This proposal will introduce a new explict class to cover this functionality, ```DispatchWorkItem``` that provides more explicit, safer typing.
+The existing ```dispatch_block_*``` API group exposes functionality that produces ```dispatch_block_t``` blocks that are wrapped with additional metadata. That behaviour in C has multiple cases where this API group can be accidentally misused because the C types are ambiguously overloaded. This proposal will introduce a new explicit class to cover this functionality, ```DispatchWorkItem``` that provides more explicit, safer typing.
 
 ```swift
 class DispatchWorkItem {

proposals/0107-unsaferawpointer.md

@@ -1771,7 +1771,7 @@ to build the standard library with the changes:
 - The type system handles implicit conversions to UnsafeRawPointer.
 
 - `UnsafeRawPointer` replaces both `UnsafePointer<Void>` and
-  `UnsafeMutablePointer<Void>` (Recent feedback suggestes that
+  `UnsafeMutablePointer<Void>` (Recent feedback suggests that
   `UnsafeMutablePointer` should also be introduced).
 
 - The standard library was relying on inferred `UnsafePointer`

proposals/0115-literal-syntax-protocols.md

@@ -79,7 +79,7 @@ All code that references any of the `*LiteralConvertible` protocols will need to
 
 Discussion of the pros and cons of the proposed and alternative naming schemes is encouraged.  The core team should feel free to choose names they deem best suited for Swift after community discussion and review if they decide to accept this proposal.
 
-The discussion thread for this proposal includes abundant bike shedding on the names.  This section includes selected examples to highlight different directions that have been discussed.  Reviewers are encouraged to read the discussion thread if they wish to see all of the alternatives.  The thread includes abundant discusison of the pros and cons of many naming ideas.
+The discussion thread for this proposal includes abundant bike shedding on the names.  This section includes selected examples to highlight different directions that have been discussed.  Reviewers are encouraged to read the discussion thread if they wish to see all of the alternatives.  The thread includes abundant discussion of the pros and cons of many naming ideas.
 
 Some of the names that have been suggested have been inaccurate due to a misunderstanding of what the protocols do.  Dave Abrahams explained during the discussion:
 

proposals/0117-non-public-subclassable-by-default.md

@@ -352,7 +352,7 @@ That is, a `public` class could be used as a compositional superclass,
 useful for adding new storage to an existing identity but not for
 messing with its invariants.  This would prevent the creation of
 sealed hierarchies and is inconsistent with the general principle
-that restrictons on future evolution should be opt-in.  Authors would
+that restrictions on future evolution should be opt-in.  Authors would
 have no ability to reserve the right to decide later whether to
 allow subclasses; declaring something `final` is irrevocable.  This
 could be added in a future extension, but it is not the right rule
@@ -396,7 +396,7 @@ We may want to reconsider the need for `final` in the light of this change.
 ## Impact on existing code
 
 This would be a backwards-breaking change for all classes and methods that are
-public and non-final, which code outside of their module has overriden.
+public and non-final, which code outside of their module has overridden.
 Those classes/methods would fail to compile. Their superclass would need to be
 changed to `open`.
 

proposals/0125-remove-nonobjectivecbase.md

@@ -15,7 +15,7 @@ Remove `NonObjectiveCBase` and
 `isUniquelyReferencedNonObjC<T: AnyObject>(_ object: T)`. This
 replacement is as performant as the call to `isUniquelyReferenced` in cases
 where the compiler has static knowledge that the type of `object` is a native
-Swift class and dyamically has the same semantics for native swift classes.
+Swift class and dynamically has the same semantics for native swift classes.
 This change will remove surface API.
 Rename `isUniquelyReferencedNonObjC` to `isKnownUniquelyReferenced` and no
 longer promise to return false for `@objc` class instances.

proposals/0143-conditional-conformances.md

@@ -396,7 +396,7 @@ There is a variation on that type,
 ReversedRandomAccessCollection<Base: RandomAccessCollection>: RandomAccessCollection
 ```
 
- that additionaly conforms to `RandomAccessCollection` when its base does.
+ that additionally conforms to `RandomAccessCollection` when its base does.
 Users create these types via the `reversed()` extension method on
 `BidirectionalCollection` and `RandomAccessCollection` respectively.
 

proposals/0145-package-manager-version-pinning.md

@@ -208,7 +208,7 @@ update` behavior described above).
 
 If a package author does check the file into source control, the effect will be
 that anyone developing directly on this package will end up sharing the same
-dependency versions (and modifications will be commited as part of the SCM
+dependency versions (and modifications will be committed as part of the SCM
 history).
 
 The automatic pinning behavior is an extension of the behaviors above, and works

proposals/0158-package-manager-manifest-api-redesign.md

@@ -218,7 +218,7 @@ access modifier is `public` for all APIs unless specified.
 * Remove implicit target dependency rule for test targets.
 
     There is an implicit test target dependency rule: a test target "FooTests"
-    implicity depends on a target "Foo", if "Foo" exists and "FooTests" doesn't
+    implicitly depends on a target "Foo", if "Foo" exists and "FooTests" doesn't
     explicitly declare any dependency. We propose to remove this rule because:
 
     1. It is a non obvious "magic" rule that has to be learned.

proposals/0159-fix-private-access-levels.md

@@ -28,7 +28,7 @@ In Swift 3 compatibility mode, the compiler will continue to treat `private` and
 
 In Swift 4 mode, the compiler will deprecate the `fileprivate` keyword and revert the semantics of the `private` access level to be file based. The migrator will rename all uses of `fileprivate` to `private`.
 
-Cases where a type had `private` declarations with the same signature in different scopes will produce a compiler error. For example, the following piece of code compiles in Swift 3 compatibilty mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode.
+Cases where a type had `private` declarations with the same signature in different scopes will produce a compiler error. For example, the following piece of code compiles in Swift 3 compatibility mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode.
 
 ```swift
 struct Foo {

proposals/0167-swift-encoders.md

@@ -40,7 +40,7 @@ open class JSONEncoder {
     ///
     /// - parameter value: The value to encode.
     /// - returns: A new `Data` value containing the encoded JSON data.
-    /// - throws: `CocoaError.coderInvalidValue` if a non-comforming floating-point value is encountered during archiving, and the encoding strategy is `.throw`.
+    /// - throws: `CocoaError.coderInvalidValue` if a non-conforming floating-point value is encountered during archiving, and the encoding strategy is `.throw`.
     /// - throws: An error if any value throws an error during encoding.
     open func encode<T : Encodable>(_ value: T) throws -> Data
 

proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

@@ -113,7 +113,7 @@ struct Outer {
 
 In Swift 3 compatibility mode, the compiler will continue to treat `private` as before. In Swift 4 mode, the compiler will modify the semantics of `private` to follow the rules of this proposal. No migration will be necessary as this proposal merely broadens the visibility of `private`.
 
-Cases where a type had `private` declarations with the same signature in the same type/extension but in different scopes will produce a compiler error in Swift 4. For example, the following piece of code compiles in Swift 3 compatibilty mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode:
+Cases where a type had `private` declarations with the same signature in the same type/extension but in different scopes will produce a compiler error in Swift 4. For example, the following piece of code compiles in Swift 3 compatibility mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode:
 
 ```swift
 struct Foo {

proposals/0171-reduce-with-inout.md

@@ -78,7 +78,7 @@ Without the `inout` parameter, we'd first have to make a `var` copy of the exist
 
 ## Source compatibility
 
-This is purely additive, we don't propose removing the existing `reduce`. Additionaly, because the first argument will have a label `into`, it doesn't add any extra burden to the type checker.
+This is purely additive, we don't propose removing the existing `reduce`. Additionally, because the first argument will have a label `into`, it doesn't add any extra burden to the type checker.
 
 ## Effect on ABI stability
 

proposals/0188-stdlib-index-types-hashable.md

@@ -28,7 +28,7 @@ let firstChar = \String.[string.startIndex]
 
 ## Proposed solution
 
-This proposal would add `Hashable` conformance to all the index types in the standard library. With that done, `[Int]`, `String`, and all other standard libary collections would have the same behavior when using subscripts in key paths.
+This proposal would add `Hashable` conformance to all the index types in the standard library. With that done, `[Int]`, `String`, and all other standard library collections would have the same behavior when using subscripts in key paths.
 
 ## Detailed design
 

proposals/0206-hashable-enhancements.md

@@ -162,7 +162,7 @@ properties:
     the input data; the hash values it produces tend to form long
     chains of sequential integer clusters. While these aren't as bad
     as hash collisions, some hash table operations can slow down
-    drasticaly when such clusters are present. (In Swift 4.1, `Set`
+    drastically when such clusters are present. (In Swift 4.1, `Set`
     and `Dictionary` use open addressing with linear probing, and they
     have to do some clever postprocessing of hash values to get rid of
     such patterns.)
@@ -194,7 +194,7 @@ regardless of their expected distributions.
 
 [SE-0185]: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
 
-Luckily, this problem has occured in other contexts before, and there
+Luckily, this problem has occurred in other contexts before, and there
 is an extensive list of hash functions that have been designed for
 exactly such cases: [Foller-Noll-Vo][FNV-1a], [MurmurHash],
 [CityHash], [SipHash], and [HighwayHash] are just a small selection of

proposals/0217-bangbang.md

@@ -180,7 +180,7 @@ In one [real-world case](http://ericasadun.com/2017/01/23/safe-programming-optio
 
 > Since IOKit just gives you back dictionaries, a missing key, is well… not there, and nil. you know how well Swift likes nils… 
 
-Applications normally can’t plan for, anticipate, or provide workarounds for code running on unofficial platforms. There are too many unforeseen factors that cannot be incorporated into realistic code that ships. Adopting a universal "unwrap or die" style with explanations enables you to "guide the landing" on these unforseen ["Black Swan"](https://en.wikipedia.org/wiki/Black_swan_theory) failures:
+Applications normally can’t plan for, anticipate, or provide workarounds for code running on unofficial platforms. There are too many unforeseen factors that cannot be incorporated into realistic code that ships. Adopting a universal "unwrap or die" style with explanations enables you to "guide the landing" on these unforeseen ["Black Swan"](https://en.wikipedia.org/wiki/Black_swan_theory) failures:
 
 ```
 guard let value = dict[guaranteedKey] 

proposals/0223-array-uninitialized-initializer.md

@@ -150,7 +150,7 @@ public init(
 ///     elements or initialize new elements.
 ///     - Parameters:
 ///       - buffer: An unsafe mutable buffer of the array's storage, covering
-///         memory for the number of elements specifed by the `capacity`
+///         memory for the number of elements specified by the `capacity`
 ///         parameter. The elements in `buffer[0..<initializedCount]` are
 ///         initialized, the memory in `buffer[initializedCount..<capacity]`
 ///         is uninitialized.

proposals/0229-simd.md

@@ -536,7 +536,7 @@ Beyond the new Swift API for vector types, there's an accompanying change to the
 importer that will allow C functions and structures using vector types to be imported. When
 we find a "clang extended vector type" or "extvector" whose underlying scalar type is
 imported as a `SIMDScalar` type in the standard library and whose element count is
-2, 3, 4, 8, 16, 32, or 64, we'll import it as the correponding standard library vector type.
+2, 3, 4, 8, 16, 32, or 64, we'll import it as the corresponding standard library vector type.
 
 ## Source compatibility
 

proposals/0230-flatten-optional-try.md

@@ -326,7 +326,7 @@ the double-optional problem.
 
 However, this change would not resolve cases of `try?` with optional chaining
 (e.g. `try? foo?.bar?.baz()`), nor cases where an optional result is returned
-directly from a funtion (e.g. `try? cachedValue(for: key)`). 
+directly from a function (e.g. `try? cachedValue(for: key)`). 
 
 Altering the binding precedence of `try?` would also be *far* more 
 source-breaking than this proposal.

proposals/0235-add-result.md

@@ -270,7 +270,7 @@ extension Result: Hashable where Success: Hashable, Failure: Hashable { }
 
 ## Adding `Swift.Error` self-conformance
 
-As part of the prepatory work for this proposal, self-conformance was added for `Error` (and only `Error`). This is also generally useful for working with errors in a generic context.
+As part of the preparatory work for this proposal, self-conformance was added for `Error` (and only `Error`). This is also generally useful for working with errors in a generic context.
 
 This self-conformance does not extend to protocol compositions including the `Error` protocol, only the exact type `Error`. It will be possible to add such compositions in the future, but that is out of scope for Swift 5.
 

proposals/0256-contiguous-collection.md

@@ -154,7 +154,7 @@ were deferred pending further use cases. This proposal is motivated by such
 cases.
 
 As mentioned in the motivation, there are some alternatives available in the
-absense of this protocol:
+absence of this protocol:
 
 - Libraries can add their own version of the protocol, and retroactively
   conform standard library types to it. This is a workable solution, but has some downsides: