[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.]

docs/PatternMatching.rst

@@ -269,7 +269,7 @@ Scoping
 
 Despite the lack of grouping braces, the semantics are that the statements in
 each case-group form their own scope, and falling off the end causes control to
-resume at the end of the switch statement — i.e. "implicit break", not "implicit
+resume at the end of the switch statement -- i.e. "implicit break", not "implicit
 fallthrough".
 
 Chris seems motivated to eventually add an explicit 'fallthrough'
@@ -285,27 +285,27 @@ grouped by braces. It's natural to group the cases with braces as well. Doing
 both lets us avoid a 'case' keyword, but otherwise it leads to ugly style,
 because either the last case ends in two braces on the same line or cases have
 to further indented. Okay, it's easy enough to not require braces on the match,
-with the grammar saying that cases are just greedily consumed — there's no
+with the grammar saying that cases are just greedily consumed -- there's no
 ambiguity here because the switch statement is necessarily within braces. But
 that leaves the code without a definitive end to the cases, and the closing
 braces end up causing a lot of unnecessary vertical whitespace, like so::
 
   switch (x)
   case .foo {
-    // …
+    // ...
   }
   case .bar {
-    // …
+    // ...
   }
 
 So instead, let's require the switch statement to have braces, and
 we'll allow the cases to be written without them::
 
   switch (x) {
   case .foo:
-    // …
+    // ...
   case .bar:
-    // …
+    // ...
   }
 
 That's really a lot prettier, except it breaks the rule about always grouping
@@ -350,8 +350,8 @@ Non-exhaustive switches
 .......................
 
 Since falling out of a statement is reasonable behavior in an
-imperative language — in contrast to, say, a functional language where
-you're in an expression and you need to produce a value — there's a
+imperative language -- in contrast to, say, a functional language where
+you're in an expression and you need to produce a value -- there's a
 colorable argument that non-exhaustive matches should be okay.  I
 dislike this, however, and propose that it should be an error to
 make a non-exhaustive switch; people who want non-exhaustive matches
@@ -527,7 +527,7 @@ major clients:
 You might think that having a "pattern" as basic as :code:`foo` mean
 something different in two different contexts would be confusing, but
 actually I don't think people will generally think of these as the
-same production — you might if you were in a functional language where
+same production -- you might if you were in a functional language where
 you really can decompose in a function signature, but we don't allow
 that, and I think that will serve to divide them in programmers' minds.
 So we can get away with some things. :)
@@ -800,7 +800,7 @@ It would be interesting to allow overloading / customization of
 pattern-matching. We may find ourselves needing to do something like this to
 support non-fragile pattern matching anyway (if there's some set of restrictions
 that make it reasonable to permit that). The obvious idea of compiling into the
-visitor pattern is a bit compelling, although control flow would be tricky —
+visitor pattern is a bit compelling, although control flow would be tricky --
 we'd probably need the generated code to throw an exception. Alternatively, we
 could let the non-fragile type convert itself into a fragile type for purposes
 of pattern matching.

docs/SequencesAndCollections.rst

@@ -14,7 +14,7 @@ taxonomy exists and how it is structured.
 Sequences
 =========
 
-It all begins with Swift's `for`\ …\ `in` loop::
+It all begins with Swift's `for`\ ...\ `in` loop::
 
   for x in s {
     doSomethingWith(x)
@@ -42,8 +42,8 @@ represented by the `SequenceType` protocol::
 
 .. sidebar:: Hiding Iterator Type Details
 
-  A sequence's iterator is an associated type—rather than something
-  like |AnyIterator|__ that depends only on the element type—for
+  A sequence's iterator is an associated type--rather than something
+  like |AnyIterator|__ that depends only on the element type--for
   performance reasons.  Although the alternative design has
   significant usability benefits, it requires one dynamic
   allocation/deallocation pair and *N* dynamic dispatches to traverse
@@ -65,7 +65,7 @@ the two kinds of sequences.
   are traversed.
 
 * **Stable** sequences, like arrays, should *not* be mutated by `for`\
-  …\ `in`, and thus require *separate traversal state*.
+  ...\ `in`, and thus require *separate traversal state*.
 
 To get an initial traversal state for an arbitrary sequence `x`, Swift
 calls `x.makeIterator()`.  The sequence delivers that state, along with
@@ -74,7 +74,7 @@ traversal logic, in the form of an **iterator**.
 Iterators
 ==========
 
-`for`\ …\ `in` needs three operations from the iterator:
+`for`\ ...\ `in` needs three operations from the iterator:
 
 * get the current element
 * advance to the next element
@@ -114,7 +114,7 @@ returning `nil` when the iterator is exhausted::
   }
 
 Combined with `SequenceType`, we now have everything we need to
-implement a generic `for`\ …\ `in` loop.
+implement a generic `for`\ ...\ `in` loop.
 
 .. sidebar:: Adding a Buffer
 
@@ -149,7 +149,7 @@ implement a generic `for`\ …\ `in` loop.
 Operating on Sequences Generically
 ----------------------------------
 
-Given an arbitrary `SequenceType`, aside from a simple `for`\ …\ `in` loop,
+Given an arbitrary `SequenceType`, aside from a simple `for`\ ...\ `in` loop,
 you can do anything that requires reading elements from beginning to
 end.  For example::
 
@@ -174,7 +174,7 @@ end.  For example::
   let s = String(array("Swift", withSeparator: "|"))
   print(s)        // "S|w|i|f|t"
 
-Because sequences may be volatile, though, you can—in general—only
+Because sequences may be volatile, though, you can--in general--only
 make a single traversal.  This capability is quite enough for many
 languages: the iteration abstractions of Java, C#, Python, and Ruby
 all go about as far as `SequenceType`, and no further.  In Swift,
@@ -230,7 +230,7 @@ how we interact with arrays: we subscript the collection using its
 
   let ith = c[i]
 
-An **index**\ —which must model `ForwardIndexType`\ —is a type with a
+An **index**\ --which must model `ForwardIndexType`\ --is a type with a
 linear series of discrete values that can be compared for equality:
 
 .. sidebar:: Dictionary Keys
@@ -365,7 +365,7 @@ All direct operations on indices are intended to be lightweight, with
 amortized O(1) complexity.  In fact, indices into `Dictionary` and
 `Set` *could* be bidirectional, but are limited to modeling
 `ForwardIndexType` because the APIs of `NSDictionary` and
-`NSSet`—which can act as backing stores of `Dictionary` and `Set`—do
+`NSSet`--which can act as backing stores of `Dictionary` and `Set`--do
 not efficiently support reverse traversal.
 
 Conclusion