[gardening] Replace likely word processor artefacts with ASCII equivalents (— → --, … → ...)

Author: practicalswift

CHANGELOG.md

@@ -327,8 +327,8 @@ using the `.dynamicType` member to retrieve the type of an expression should mig
   ```swift
   let a: Foo & Bar
   let b = value as? A & B & C
-  func foo<T : Foo & Bar>(x: T) { … }
-  func bar(x: Foo & Bar) { … }
+  func foo<T : Foo & Bar>(x: T) { ... }
+  func bar(x: Foo & Bar) { ... }
   typealias G = GenericStruct<Foo & Bar>
   ```
 
@@ -1106,7 +1106,7 @@ Swift 2.0
 * Public extensions of generic types are now permitted.
 
   ```swift
-  public extension Array { … }
+  public extension Array { ... }
   ```
 
   **(16974298)**
@@ -1266,8 +1266,8 @@ Swift 2.0
   For example:
 
   ```swift
-  func produceGizmoUsingTechnology() throws -> Gizmo { … }
-  func produceGizmoUsingMagic() throws -> Gizmo { … }
+  func produceGizmoUsingTechnology() throws -> Gizmo { ... }
+  func produceGizmoUsingMagic() throws -> Gizmo { ... }
 
   if let result = try? produceGizmoUsingTechnology() { return result }
   if let result = try? produceGizmoUsingMagic() { return result }
@@ -1440,7 +1440,7 @@ Swift 2.0
   function or initializer. For example:
 
   ```swift
-  func doSomethingToValues(values: Int... , options: MyOptions = [], fn: (Int) -&gt; Void) { … }
+  func doSomethingToValues(values: Int... , options: MyOptions = [], fn: (Int) -&gt; Void) { ... }
   ```
 
   **(20127197)**
@@ -1472,7 +1472,7 @@ Swift 2.0
   **(17227475)**
 
 * When delegating or chaining to a failable initializer (for example, with
-  `self.init(…)` or `super.init(…)`), one can now force-unwrap the result with
+  `self.init(...)` or `super.init(...)`), one can now force-unwrap the result with
   `!`. For example:
 
   ```swift
@@ -2179,7 +2179,7 @@ Swift 1.2
   }
 
   class MySomethingDelegate : SomethingDelegate {
-      @objc func didSomething() { … }
+      @objc func didSomething() { ... }
   }
   ```
 

benchmark/README.md

@@ -156,11 +156,11 @@ To add a new multiple file test:
 1.  Add a new directory and files under the `multi-source` directory as
     specified below:
 
-        ├── multi-source
-        │   ├── YourTestName
-        │   │   ├── TestFile1.swift
-        │   │   ├── TestFile2.swift
-        │   │   ├── TestFile3.swift
+        +-- multi-source
+        |   +-- YourTestName
+        |   |   +-- TestFile1.swift
+        |   |   +-- TestFile2.swift
+        |   |   +-- TestFile3.swift
 
     At least one run function (specified in the template below) must
     exist in the files.

docs/AccessControl.rst

@@ -21,8 +21,8 @@ future, ``public`` may be used for both API and SPI, at which point we may
 design additional annotations to distinguish the two.
 
 By default, most entities in a source file have ``internal`` access.
-This optimizes for the most common case—a single-target application
-project—while not accidentally revealing entities to clients of a framework
+This optimizes for the most common case--a single-target application
+project--while not accidentally revealing entities to clients of a framework
 module.
 
 .. warning:: This document has not yet been updated for SE-0117, which adds the

docs/AccessControlInStdlib.rst

@@ -54,7 +54,7 @@ To document the reason for marking symbols public, we use comments:
 `internal`
 ==========
 
-In Swift, `internal` is an implied default everywhere—except within
+In Swift, `internal` is an implied default everywhere--except within
 `public` extensions and protocols.  Therefore, `internal` should be used
 explicitly everywhere in the stdlib to avoid confusion.
 

docs/Arrays.rst

@@ -53,14 +53,14 @@ Swift provides three generic array types, all of which have amortized
 O(1) growth.  In this document, statements about **ArrayType** apply
 to all three of the components.
 
-* ``ContiguousArray<Element>`` is the fastest and simplest of the three—use
+* ``ContiguousArray<Element>`` is the fastest and simplest of the three--use
   this when you need "C array" performance.  The elements of a
   ``ContiguousArray`` are always stored contiguously in memory.
 
   .. image:: ContiguousArray.png
 
 * ``Array<Element>`` is like ``ContiguousArray<Element>``, but optimized for
-  efficient conversions from Cocoa and back—when ``Element`` can be a class
+  efficient conversions from Cocoa and back--when ``Element`` can be a class
   type, ``Array<Element>`` can be backed by the (potentially non-contiguous)
   storage of an arbitrary ``NSArray`` rather than by a Swift
   ``ContiguousArray``.  ``Array<Element>`` also supports up- and downcasts
@@ -227,7 +227,7 @@ TODO: this section is outdated.
 
 When up-casting an ``[Derived]`` to ``[Base]``, a buffer of
 ``Derived`` object can simply be ``unsafeBitCast``\ 'ed to a buffer
-of elements of type ``Base``—as long as the resulting buffer is never
+of elements of type ``Base``--as long as the resulting buffer is never
 mutated.  For example, we cannot allow a ``Base`` element to be
 inserted in the buffer, because the buffer's destructor will destroy
 the elements with the (incorrect) static presumption that they have

docs/GenericsManifesto.md

@@ -369,7 +369,7 @@ func apply<... Args, Result>(fn: (Args...) -> Result,    // function taking some
 
 ### Extensions of structural types
 
-Currently, only nominal types (classes, structs, enums, protocols) can be extended. One could imagine extending structural types—particularly tuple types—to allow them to, e.g., conform to protocols. For example, pulling together variadic generics, parameterized extensions, and conditional conformances, one could express "a tuple type is `Equatable` if all of its element types are `Equatable`":
+Currently, only nominal types (classes, structs, enums, protocols) can be extended. One could imagine extending structural types--particularly tuple types--to allow them to, e.g., conform to protocols. For example, pulling together variadic generics, parameterized extensions, and conditional conformances, one could express "a tuple type is `Equatable` if all of its element types are `Equatable`":
 
 ```Swift
 extension<...Elements : Equatable> (Elements...) : Equatable {   // extending the tuple type "(Elements...)" to be Equatable
@@ -450,7 +450,7 @@ The `where` clause of generic functions comes very early in the declaration, alt
 func containsAll<S: Sequence where Sequence.Iterator.Element == Element>(elements: S) -> Bool
 ```
 
-One could move the `where` clause to the end of the signature, so that the most important parts—name, generic parameter, parameters, result type—precede it:
+One could move the `where` clause to the end of the signature, so that the most important parts--name, generic parameter, parameters, result type--precede it:
 
 ```Swift
 func containsAll<S: Sequence>(elements: S) -> Bool
@@ -636,7 +636,7 @@ func foo(value: Any) {
 foo(X())
 ```
 
-Under what circumstances should it print "P"? If `foo()` is defined within the same module as the conformance of `X` to `P`? If the call is defined within the same module as the conformance of `X` to `P`? Never? Either of the first two answers requires significant complications in the dynamic casting infrastructure to take into account the module in which a particular dynamic cast occurred (the first option) or where an existential was formed (the second option), while the third answer breaks the link between the static and dynamic type systems—none of which is an acceptable result.
+Under what circumstances should it print "P"? If `foo()` is defined within the same module as the conformance of `X` to `P`? If the call is defined within the same module as the conformance of `X` to `P`? Never? Either of the first two answers requires significant complications in the dynamic casting infrastructure to take into account the module in which a particular dynamic cast occurred (the first option) or where an existential was formed (the second option), while the third answer breaks the link between the static and dynamic type systems--none of which is an acceptable result.
 
 ### Conditional conformances via protocol extensions
 

docs/GitWorkflows.rst

@@ -11,9 +11,9 @@ Purpose
 Swift development has been based on SVN since its inception.  As part of the
 transition to Git this document helps to address questions about how common SVN
 workflows we use today translate to their Git counterparts as well as to discuss
-Git workflow practices we plan on having — at least initially — after the Git
-transition.  Notably we will follow a model where commits to trunk — which is
-the 'master' branch in Git — has commits land (in the common case) via rebasing
+Git workflow practices we plan on having -- at least initially -- after the Git
+transition.  Notably we will follow a model where commits to trunk -- which is
+the 'master' branch in Git -- has commits land (in the common case) via rebasing
 instead of merging.  This model is open to evolution later, but this mimics the
 workflow we have today with SVN.
 

docs/InitializerProblems.rst

@@ -60,7 +60,7 @@ Problem 3: Factory Initializers
 ===============================
 
 Finally, we try to standardize on initializers for object creation in Swift,
-even going as far as to import Objective-C factory methods as initializers…but
+even going as far as to import Objective-C factory methods as initializers...but
 there are some patterns that cannot be written in Swift, such as this one::
 
     class AnyGenerator<Element> : GeneratorType {

docs/LibraryEvolution.rst

@@ -128,7 +128,7 @@ specifying the name of the client library along with the required version::
 
     // Client code
     @available(Magician 1.5)
-    class CrystalBallView : MagicView { /*…*/ }
+    class CrystalBallView : MagicView { /*...*/ }
 
 Library versions can also be checked dynamically using ``#available``, allowing
 for fallback behavior when the requested library version is not present::
@@ -393,7 +393,7 @@ example using methods::
 
     public struct Point2D {
       var x, y: Double
-      public init(x: Double, y: Double) { /*…*/ }
+      public init(x: Double, y: Double) { /*...*/ }
     }
 
     extension Point2D {
@@ -410,7 +410,7 @@ polar representation::
 
     public struct Point2D {
       var r, theta: Double
-      public init(x: Double, y: Double) { /*…*/ }
+      public init(x: Double, y: Double) { /*...*/ }
     }
 
 and the ``x`` and ``y`` properties have now disappeared. To avoid this, the
@@ -659,13 +659,13 @@ can enforce its safe use.
 We've considered two possible syntaxes for this::
 
     @available(1.1)
-    extension Wand : MagicType {/*…*/}
+    extension Wand : MagicType {/*...*/}
 
 and
 
 ::
 
-    extension Wand : @available(1.1) MagicType {/*…*/}
+    extension Wand : @available(1.1) MagicType {/*...*/}
 
 The former requires fewer changes to the language grammar, but the latter could
 also be used on the declaration of the type itself (i.e. the ``struct``

docs/MutationModel.rst

@@ -106,7 +106,7 @@ The implicit ``self`` parameter of a struct or enum method is semantically an
 objects.
 
 A program that applies the ``mutating`` to a method of a
-class—or of a protocol attributed with ``@class_protocol``—is
+class--or of a protocol attributed with ``@class_protocol``--is
 ill-formed.  [Note: it is logically consistent to think of all methods
 of classes as read-only, even though they may in fact modify instance
 variables, because they never "write back" onto the source reference.]