[Proposals] fix typos in 90+ proposals

Author: Sajjon

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/0018-flexible-memberwise-initialization.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/0026-abstract-classes-and-methods.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/0058-objectivecbridgeable.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/0073-noescape-once.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/0075-import-test.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/0082-swiftpm-package-edit.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/0088-libdispatch-for-swift3.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/0099-conditionclauses.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