[Proposals] fix typos in 90+ proposals

proposals/0006-apply-api-guidelines-to-the-standard-library.md

@@ -1144,7 +1144,7 @@ public struct OpaquePointer : ... {
 -    allowedCharacters: NSCharacterSet
 -  ) -> String?
 +  public func addingPercentEncoding(
-+    withAllowedCharaters allowedCharacters: NSCharacterSet
++    withAllowedCharacters allowedCharacters: NSCharacterSet
 +  ) -> String?
 
 -  public func stringByAddingPercentEscapesUsingEncoding(

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

@@ -16,7 +16,7 @@ in inherited class like protocols.
 
 ## Motivation
 
-like pure virtual methods in C++ and abtract classes in Java and C#, frameworks development 
+like pure virtual methods in C++ and abstract classes in Java and C#, frameworks development 
 sometimes required abstract classes facility.
 An abstract class is like a regular class, but some methods/properties are not implemented 
 and must be implemented in one of inherited classes.
@@ -97,7 +97,7 @@ class MyRestServiceClient : RESTClient {
 ```
 
 ## Detailed design
-An abstract class cannot be instanciated. 
+An abstract class cannot be instantiated. 
 
 Abstract method/property cannot have implementation.
 

proposals/0058-objectivecbridgeable.md

@@ -77,7 +77,7 @@ public protocol ObjectiveCBridgeable {
     /// Objective-C thunk or when calling Objective-C code.
     ///
     /// - note: This initializer should eagerly perform the
-    /// conversion without defering any work for later,
+    /// conversion without deferring any work for later,
     /// returning `nil` if the conversion fails.
     init?(bridgedFromObjectiveC: ObjectiveCType)
 
@@ -144,7 +144,7 @@ The compiler generates automatic thunks only when there is no ambiguity, while e
     3. Bridged collection types will still observe the protocol conformance if cast to a Swift type (eg: `NSArray as? [Int]` will call the `ObjectiveCBridgeable` implementation on `Array`, which itself will call the implementation on `Int` for the elements)
 2. A Swift type may bridge to an Objective-C base class then provide different subclass instances at runtime, but no other Swift type may bridge to that base class or any of its subclasses.
     1. The compiler should emit a diagnostic when it detects two Swift types attempting to bridge to the same `ObjectiveCType`.
-3. An exception to these rules exists for trivially convertable built-in types like `NSInteger` <--> `Int` when specified outside of a bridged collection type. In those cases the compiler will continue the existing behavior, bypassing the `ObjectiveCBridgeable` protocol. The effect is that types like `Int` will not bridge to `NSNumber` unless contained inside a collection type (see `BuiltInBridgeable below`).
+3. An exception to these rules exists for trivially convertible built-in types like `NSInteger` <--> `Int` when specified outside of a bridged collection type. In those cases the compiler will continue the existing behavior, bypassing the `ObjectiveCBridgeable` protocol. The effect is that types like `Int` will not bridge to `NSNumber` unless contained inside a collection type (see `BuiltInBridgeable below`).
 
 ### Resiliance
 

proposals/0073-noescape-once.md

@@ -128,7 +128,7 @@ expected.
 ## Not requiring exactly one execution
 
 Assuming that the main goal of this proposal is to relax initialization
-requirements, a unique invocation of the closure is not stricly required.
+requirements, a unique invocation of the closure is not strictly required.
 However the requirement of unique invocation makes the proposal simpler to
 understand.
 

proposals/0075-import-test.md

@@ -33,7 +33,7 @@ Swift's existing set of build configurations specify platform differences, not m
 #endif
 ```
 
-Guarding code with operating system tests can be less future-proofed than testing for module support.  Excluding OS X to use UIColor creates code that might eventually find its way to a Linux plaform. Targeting Apple platforms by inverting a test for Linux essentially broke after the introduction of `Windows` and `FreeBSD` build configurations:
+Guarding code with operating system tests can be less future-proofed than testing for module support.  Excluding OS X to use UIColor creates code that might eventually find its way to a Linux platform. Targeting Apple platforms by inverting a test for Linux essentially broke after the introduction of `Windows` and `FreeBSD` build configurations:
 
 ```swift
 // Exclusive os tests are brittle

proposals/0082-swiftpm-package-edit.md

@@ -93,7 +93,7 @@ This solution is intended to directly address the desired behaviors of the
 package manager:
 
 * By hiding the sources by default, we minimize the distractions in the common
-  case where a user is programming against a known, well-establised, library
+  case where a user is programming against a known, well-established, library
   they do not need to modify.
 
 * By adding a new, explicit workflow for switching to an "editable" package, we

proposals/0088-libdispatch-for-swift3.md

@@ -259,7 +259,7 @@ struct DispatchData : RandomAccessCollection, _ObjectiveCBridgeable {
 }
 ```
 
-This proposal will introduce new accessor methods to access the bytes in a Data object. Along with becoming iteratable, several methods will be introduced that replace the ```dispatch_data_create_map``` approach used in C:
+This proposal will introduce new accessor methods to access the bytes in a Data object. Along with becoming iterable, several methods will be introduced that replace the ```dispatch_data_create_map``` approach used in C:
 
 ```swift
 struct DispatchData : RandomAccessCollection, _ObjectiveCBridgeable {

proposals/0099-conditionclauses.md

@@ -9,7 +9,7 @@
 
 ## Introduction
 
-Swift condition clauses appear in `guard`, `if`, and `while` statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, `let` conditions (which test and unwrap optionals), general `case` clauses for arbitrary pattern matching, and availability tests.  It removes `where` clauses from optional binding conditions and case conditions, and eliminates gramatical ambiguity by using commas for separation between clauses instead of using them both to separate clauses and terms within each clause.  These modifications streamline Swift's syntax and alleviate the situation where many Swift developers don't know they can use arbitrary Boolean conditions after a value binding.
+Swift condition clauses appear in `guard`, `if`, and `while` statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, `let` conditions (which test and unwrap optionals), general `case` clauses for arbitrary pattern matching, and availability tests.  It removes `where` clauses from optional binding conditions and case conditions, and eliminates grammatical ambiguity by using commas for separation between clauses instead of using them both to separate clauses and terms within each clause.  These modifications streamline Swift's syntax and alleviate the situation where many Swift developers don't know they can use arbitrary Boolean conditions after a value binding.
 
 Swift-evolution thread:
 [\[Pitch\] making where and ,	interchangeable in guard conditions](https://forums.swift.org/t/pitch-making-where-and-interchangeable-in-guard-conditions/2702)

proposals/0106-rename-osx-to-macos.md

@@ -73,7 +73,7 @@ This proposal is purely additive. It will not affect existing code other than ad
 
 Instead of retaining and aliasing `os(OSX)`, it can be fully replaced by `os(macOS)`. This mirrors the situation with the phoneOS to iOS rename and would require a migration assistant to fixit old-style use. 
 
-Charlie Monroe points out: "Since Swift 3.0 is a code-breaking change my guess is that there is no burden if the Xcode migration assistent automatically changes all `#if os(OSX)` to `#if os(macOS)`, thus deprecating the term OSX, not burdening the developer at all. If iOS was renamed to phoneOS and kept versioning, you'd still expect `#if os(iOS)` to be matched when targeting phoneOS and vice-versa."
+Charlie Monroe points out: "Since Swift 3.0 is a code-breaking change my guess is that there is no burden if the Xcode migration assistant automatically changes all `#if os(OSX)` to `#if os(macOS)`, thus deprecating the term OSX, not burdening the developer at all. If iOS was renamed to phoneOS and kept versioning, you'd still expect `#if os(iOS)` to be matched when targeting phoneOS and vice-versa."
 
 ## Unaddressed Issues
 

proposals/0107-unsaferawpointer.md

@@ -160,7 +160,7 @@ value argument could result in miscompilation if the inferred type
 ever deviates from the user's original expectations. The type
 parameter also importantly conveys that the raw memory becomes
 accessible via a pointer to that type at the point of the call. The
-type should be explicitly spelled at this point because accesing the
+type should be explicitly spelled at this point because accessing the
 memory via a typed pointer of an unrelated type could also result in
 miscompilation.
 

proposals/0108-remove-assoctype-inference.md

@@ -165,7 +165,7 @@ There are some advantages to this approach. Brevity is slightly improved. A type
 
 As well, Dave Abrahams expresses a [potential issue](https://forums.swift.org/t/pitch-remove-type-inference-for-associated-types/3135/17):
 
-> Finally, I am very concerned that there are protocols such as `Collection`, with many inferrable associated types, and that conforming to these protocols could become *much* uglier.
+> Finally, I am very concerned that there are protocols such as `Collection`, with many inferable associated types, and that conforming to these protocols could become *much* uglier.
 
 As with many proposals, there is a tradeoff between the status quo and the proposed behavior. As *Completing Generics* puts it,
 

proposals/0119-extensions-access-modifiers.md

@@ -56,7 +56,7 @@ This simple access control model also allows us to nest types inside each other
 
 *Extensions* however behave differently when it comes to their access control:
 
-* The *access modifier* of an *extension* sets the default modifier of its members which do not have their own localy defined modifier.
+* The *access modifier* of an *extension* sets the default modifier of its members which do not have their own locally defined modifier.
 
 	```swift
 	public struct D {}
@@ -234,7 +234,7 @@ I propose to revise the access control on extensions by removing access modifier
 		
 		fileprivate group {
 		
-			// Every group memebr is `fileprivate`
+			// Every group member is `fileprivate`
 			func member1() {}
 			func member2() {}
 			func member3() {}
@@ -286,7 +286,7 @@ Iff the *access-level-modifier* is not present, the access modifier on extension
 ```diff
 - extension SomeType : SomeProtocol {
 + public extension SomeType : SomeProtocol {
-	public func someMemeber()
+	public func someMember()
 }
 ```
 

proposals/0138-unsaferawbufferpointer.md

@@ -32,7 +32,7 @@ for binding memory to a type for subsequent normal typed
 access. However, migration is not always straightforward because
 SE-0107 provided only minimal support for raw pointers. Extending raw
 pointer support to the `UnsafeBufferPointer` type will fill in this
-funcionality gap. This is especially important for code that currently
+functionality gap. This is especially important for code that currently
 views "raw" bytes of memory as
 `UnsafeBufferPointer<UInt8>`. Converting between `UInt8` and the
 client's element type at every API transition is difficult to do
@@ -69,7 +69,7 @@ is natural for the same type that encapsulates a raw pointer and
 length to also allow clients to view that memory as raw bytes without the
 need to explicitly bind the memory type each time memory is
 accessed. This would also improve performance in some cases that I've
-encoutered by avoiding array copies. Let's call this new type
+encountered by avoiding array copies. Let's call this new type
 `Unsafe[Mutable]RawBufferPointer`.
 
 Any array could be viewed as `UnsafeRawBufferPointer`, and that raw
@@ -488,7 +488,7 @@ collection of bytes, so there's no loss in functionality:
 ```swift
 public final class BufferedOutputByteStream: OutputByteStream {
     // FIXME: For inmemory implementation we should be share this buffer with OutputByteStream.
-    // One way to do this is by allowing OuputByteStream to install external buffers.
+    // One way to do this is by allowing OutputByteStream to install external buffers.
     private var contents = [UInt8]()
 
   override final func writeImpl(_ bytes: UnsafeRawBufferPointer) {

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

@@ -366,7 +366,7 @@ specification in the manifest (which is the "requirement"). The meaning of pin
 connotes this transient relationship between the pin action and the underlying
 dependency.
 
-In constrast, not only does lock have the wrong connotation, but it also is a
+In contrast, not only does lock have the wrong connotation, but it also is a
 heavily overloaded word which can lead to confusion. For example, if the package
 manager used POSIX file locking to prevent concurrent manipulation of packages
 (a feature we intend to implement), and we also referred to the pinning files as

proposals/0147-move-unsafe-initialize-from.md

@@ -54,7 +54,7 @@ Therefore:
 - Over-allocating the destination buffer relative to `underestimatedCount` is valid and simply results in sequence underflow with potentially uninitialized buffer memory (a likely case with arrays that reserve more than they need).
 - The source sequence's actual count may exceed both `underestimatedCount` and the destination buffer size, resulting in sequence overflow. This is also valid and handled by returning an iterator to the uncopied elements as an overflow sequence.
 
-A matching change should also be made to `UnsafeRawBufferPointer.initializeMemory(from:)`. The one difference is that for convenience this should return an `UnsafeMutableBufferPointer` of the (typed) intialized elements instead of an index into the raw buffer.
+A matching change should also be made to `UnsafeRawBufferPointer.initializeMemory(from:)`. The one difference is that for convenience this should return an `UnsafeMutableBufferPointer` of the (typed) initialized elements instead of an index into the raw buffer.
 
 ## Detailed design
 

proposals/0156-subclass-existentials.md

@@ -190,7 +190,7 @@ let myViewController = MyViewController()
 myViewController.setup(UIViewController())
 ```
 
-The previous code continues to compile but still crashs if the Objective-C code calls a method of `UITableViewDataSource` or `UITableViewDelegate`. But if this proposal is accepted and implemented as-is, the Objective-C code will be imported in Swift 4 mode as:
+The previous code continues to compile but still crashes if the Objective-C code calls a method of `UITableViewDataSource` or `UITableViewDelegate`. But if this proposal is accepted and implemented as-is, the Objective-C code will be imported in Swift 4 mode as:
 
 ```swift
 class MyViewController {

proposals/0162-package-manager-custom-target-layouts.md

@@ -91,7 +91,7 @@ remember.
       consider upgrading this to its own type to allow per-file build settings.
       The new type would conform to `CustomStringConvertible`, so existing
       declarations would continue to work (except where the strings were
-      constructed programatically).
+      constructed programmatically).
 
     * `exclude`: This property can be used to exclude certain files and
       directories from being picked up as sources. Exclude paths are relative

proposals/0172-one-sided-ranges.md

@@ -64,7 +64,7 @@ variants of `Sequence.enumerated()` when you either want them non-zero-based
 i.e. `zip(1..., greeting)`, or want to flip the order i.e. `zip(greeting,
 0...)`.
 
-This syntax would supercede the existing `prefix` and `suffix` operations that
+This syntax would supersede the existing `prefix` and `suffix` operations that
 take indices, which will be deprecated in a later release. Note that the
 versions that take distances are not covered by this proposal, and would remain.
 
@@ -171,7 +171,7 @@ extension MutableCollection {
    where R.Bound == Index { get set }
 }
 
-extension RangeReplaceableColleciton {
+extension RangeReplaceableCollection {
   public mutating func replaceSubrange<C: Collection, R: RangeExpression>(
     _ subrange: ${Range}<Index>, with newElements: C
   ) where C.Iterator.Element == Iterator.Element, R.Bound == Index

proposals/0173-swap-indices.md

@@ -82,7 +82,7 @@ protocol MutableCollection {
 The current `swap` is required to `fatalError` on attempts to swap an element
 with itself for implementation reasons. This pushes the burden to check this
 first onto the caller. While swapping an element with itself is often a logic
-errror (for example, in a `sort` algorithm where you have a fenceposts bug), it
+error (for example, in a `sort` algorithm where you have a fenceposts bug), it
 is occasionally a valid situation (for example, it can occur easily in an
 implementation of `shuffle`). This implementation removes the precondition.
 

proposals/0174-filter-range-replaceable.md

@@ -70,7 +70,7 @@ They may be be relying on an array being returned (albeit often in order to
 then transform it back into the original type), but this version will still
 be available (via the extension on `Sequence`) and will be called if forced
 through type context. The only code that will break is if this operation spans
-multple lines:
+multiple lines:
 
 ```swift
 // filtered used to be [Character], now String

proposals/0176-enforce-exclusive-access-to-memory.md

@@ -740,7 +740,7 @@ automatically to avoid source-compatibility problems.
 
 ## Effect on ABI stability and resilience
 
-In order to gain the performance and language-desing benefits of
+In order to gain the performance and language-design benefits of
 exclusivity, we must be able to assume that it is followed faithfully
 in various places throughout the ABI.  Therefore, exclusivity must be
 enforced before we commit to a stable ABI, or else we'll be stuck with

proposals/0180-string-index-overhaul.md

@@ -129,7 +129,7 @@ let tagEnd = html.utf16[tagStart...].index(of: close)
 let tag = html[tagStart...tagEnd]
 ```
 
-A property and an intializer will be added to `String.Index`, exposing
+A property and an initializer will be added to `String.Index`, exposing
 the offset of the index in code units (currently only UTF-16) from the
 beginning of the string:
 

proposals/0183-substring-affordances.md

@@ -74,7 +74,7 @@ case of `filter`).
 
 ## Effect on ABI stability
 
-The switch from conrete to generic types needs to be made before ABI stability.
+The switch from concrete to generic types needs to be made before ABI stability.
 
 ## Alternatives considered
 

proposals/0193-cross-module-inlining-and-specialization.md

@@ -171,7 +171,7 @@ The closest analogue in C to `@usableFromInline` is a non-`static` function that
 
 ## Alternatives considered
 
-One possible alterative would be to add a new compiler mode where _all_ declarations become implicitly `@inlinable`, and _all_ private and internal declarations become `@usableFromInline`.
+One possible alternative would be to add a new compiler mode where _all_ declarations become implicitly `@inlinable`, and _all_ private and internal declarations become `@usableFromInline`.
 
 However, such a compilation mode would not solve the problem of delivering a stable ABI and standard library which can be deployed separately from user code. We _don't want_ all declaration bodies in the standard library to be available to the optimizer when building user code.
 

proposals/0196-diagnostic-directives.md

@@ -155,7 +155,7 @@ On February 1, 2018 the Core Team decided to **accept** this proposal with
 slight revision over the [original proposal](https://github.com/swiftlang/swift-evolution/blob/ab0c22a2340be9bfcb82e6f237752b4d959a93b7/proposals/0196-diagnostic-directives.md).
 
 The only revision over the original proposal is to change the syntax to use
-`#warning(<Message>)` instead of `#warning <Messsage>`.  This fits well with
+`#warning(<Message>)` instead of `#warning <Message>`.  This fits well with
 most of Swift's existing compiler directives, and was strongly supported in
 the [review discussion](https://forums.swift.org/t/se-0196-compiler-diagnostic-directives/8734).
 

proposals/0198-playground-quicklook-api-revamp.md

@@ -261,7 +261,7 @@ support the replacement of `CustomPlaygroundQuickLookable` with
 `CustomPlaygroundDisplayConvertible`. Instead, we intend for Swift 4.1 to be a
 deprecation period for these APIs, allowing any code bases which implement
 `CustomPlaygroundQuickLookable` to manually switch to the new protocol. While
-this migration may not be trivial programatically, it should -- in most cases --
+this migration may not be trivial programmatically, it should -- in most cases --
 be fairly trivial for someone to hand-migrate to
 `CustomPlaygroundDisplayConvertible`. During the deprecation period, the
 PlaygroundLogger framework will continue to honor implementations of