[gardening] Consistently use normal quotes ("…") instead of curly quotes (“…”)

docs/AccessControlInStdlib.rst

@@ -6,7 +6,7 @@ Scope and introduction
 This document defines the policy for applying access control modifiers and
 related naming conventions for the Swift standard library and overlays.
 
-In this document, “stdlib” refers to the core standard library and
+In this document, "stdlib" refers to the core standard library and
 overlays for system frameworks written in Swift.
 
 Swift has three levels of access control --- private, internal
@@ -60,7 +60,7 @@ explicitly everywhere in the stdlib to avoid confusion.
 
 .. Note:: No declaration should omit an access
 
-To create a “single point of truth” about whether a name is intended
+To create a "single point of truth" about whether a name is intended
 for user consumption, the following names should all use the `leading
 underscore rule`_:
 

docs/MutationModel.rst

@@ -37,7 +37,7 @@ Consider::
   }
 
   var w = Window()
-  w.title += " (parenthesized remark)”
+  w.title += " (parenthesized remark)"
 
 What do we do with this?  Since ``+=`` has an ``inout`` first
 argument, we detect this situation statically (hopefully one day we’ll
@@ -101,14 +101,14 @@ Otherwise, it is considered **read-only**.
 
 The implicit ``self`` parameter of a struct or enum method is semantically an
 ``inout`` parameter if and only if the method is attributed with
-``mutating``.  Read-only methods do not “write back” onto their target
+``mutating``.  Read-only methods do not "write back" onto their target
 objects.
 
 A program that applies the ``mutating`` to a method of a
 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.]
+variables, because they never "write back" onto the source reference.]
 
 Mutating Operations
 -------------------

docs/OptimizerDesign.md

@@ -25,7 +25,7 @@ phase (stands for intermediate representation generation phase) that lowers SIL
 into LLVM IR. The LLVM backend optimizes and emits binary code for the compiled
 program.
 
-Please refer to the document “Swift Intermediate Language (SIL)” for more
+Please refer to the document "Swift Intermediate Language (SIL)" for more
 details about the SIL IR.
 
 The compiler optimizer is responsible for optimizing the program using the
@@ -125,8 +125,8 @@ The mechanism that swift uses to invalidate analysis is broadcast-invalidation.
 Passes ask the pass manager to invalidate specific traits. For example, a pass
 like simplify-cfg will ask the pass manager to announce that it modified some
 branches in the code. The pass manager will send a message to all of the
-available analysis that says “please invalidate yourself if you care about
-branches for function F“. The dominator tree would then invalidate the dominator
+available analysis that says "please invalidate yourself if you care about
+branches for function F". The dominator tree would then invalidate the dominator
 tree for function F because it knows that changes to branches can mean that the
 dominator tree was modified.
 
@@ -189,7 +189,7 @@ functions with the @_semantics attribute until after all of the data-structure
 specific optimizations are done. Unfortunately, this lengthens our optimization
 pipeline.
 
-Please refer to the document “High-Level SIL Optimizations” for more details.
+Please refer to the document "High-Level SIL Optimizations" for more details.
 
 
 ### Instruction Invalidation in SIL
@@ -241,4 +241,4 @@ TODO.
 
 ### List of passes
 
-The updated list of passes is available in the file “Passes.def”.
+The updated list of passes is available in the file "Passes.def".

docs/SIL.rst

@@ -594,7 +594,7 @@ generic constraints:
   * Non-class protocol types
   * @weak types
 
-  Values of address-only type (“address-only values”) must reside in
+  Values of address-only type ("address-only values") must reside in
   memory and can only be referenced in SIL by address. Addresses of
   address-only values cannot be loaded from or stored to. SIL provides
   special instructions for indirectly manipulating address-only

docs/SequencesAndCollections.rst

@@ -60,8 +60,8 @@ As you can see, sequence does nothing more than deliver a generator.
 To understand the need for generators, it's important to distinguish
 the two kinds of sequences.
 
-* **Volatile** sequences like “stream of network packets,” carry
-  their own traversal state, and are expected to be “consumed” as they
+* **Volatile** sequences like "stream of network packets," carry
+  their own traversal state, and are expected to be "consumed" as they
   are traversed.
 
 * **Stable** sequences, like arrays, should *not* be mutated by `for`\
@@ -215,7 +215,7 @@ that stability in generic code, we'll need another protocol.
 Collections
 ===========
 
-A **collection** is a stable sequence with addressable “positions,”
+A **collection** is a stable sequence with addressable "positions,"
 represented by an associated `Index` type::
  
   protocol CollectionType : SequenceType {

docs/StdlibAPIGuidelines.rst

@@ -102,7 +102,7 @@ Subsequent Parameters
 Other Differences
 -----------------
 
-* We don't use namespace prefixes such as “`NS`”, relying instead on
+* We don't use namespace prefixes such as "`NS`", relying instead on
   the language's own facilities.
 
 * Names of types, protocols and enum cases are `UpperCamelCase`.
@@ -156,7 +156,7 @@ library, but are compatible with the Cocoa guidelines.
     }
 
 * Even unlabelled parameter names should be meaningful as they'll be
-  referred to in comments and visible in “generated headers”
+  referred to in comments and visible in "generated headers"
   (cmd-click in Xcode):
 
   .. parsed-literal::
@@ -205,7 +205,7 @@ Acceptable Short or Non-Descriptive Names
 Prefixes and Suffixes
 ---------------------
 
-* `Any` is used as a prefix to denote “type erasure,”
+* `Any` is used as a prefix to denote "type erasure,"
   e.g. `AnySequence<T>` wraps any sequence with element type `T`,
   conforms to `SequenceType` itself, and forwards all operations to the
   wrapped sequence.  When handling the wrapper, the specific type of 

docs/StdlibRationales.rst

@@ -64,7 +64,7 @@ generally *should* use a keyword.  For example, ``String(33, radix:
    they're converting.  Secondly, avoiding method or property syntax
    provides a distinct context for code completion.  Rather than
    appearing in completions offered after ``.``, for example, the
-   available conversions could show up whenever the user hit the “tab”
+   available conversions could show up whenever the user hit the "tab"
    key after an expression.
 
 Protocols with restricted conformance rules

docs/StringDesign.rst

@@ -116,9 +116,9 @@ Goals
 ``String`` should:
 
 * honor industry standards such as Unicode
-* when handling non-ASCII text, deliver “reasonably correct”
+* when handling non-ASCII text, deliver "reasonably correct"
   results to users thinking only in terms of ASCII
-* when handling ASCII text, provide “expected behavior” to users
+* when handling ASCII text, provide "expected behavior" to users
   thinking only in terms of ASCII
 * be hard to use incorrectly
 * be easy to use correctly
@@ -165,7 +165,7 @@ optimizations, including:
 - In-place modification of uniquely-owned buffers
 
 As a result, copying_ and slicing__ strings, in particular, can be
-viewed by most programmers as being “almost free.”
+viewed by most programmers as being "almost free."
 
 __ sliceable_
 
@@ -197,7 +197,7 @@ Strings are **Value Types**
 Distinct string variables have independent values: when you pass
 someone a string they get a copy of the value, and when someone
 passes you a string *you own it*.  Nobody can change a string value
-“behind your back.”
+"behind your back."
 
 .. parsed-literal::
   |swift| class Cave {
@@ -231,18 +231,18 @@ Strings are **Unicode-Aware**
    specifies requires careful justification.  So far, we have found two
    possible points of deviation for Swift ``String``:
 
-   1. The `Unicode Text Segmentation Specification`_ says, “`do not
-      break between CR and LF`__.”  However, breaking extended
+   1. The `Unicode Text Segmentation Specification`_ says, "`do not
+      break between CR and LF`__."  However, breaking extended
       grapheme clusters between CR and LF may necessary if we wish
-      ``String`` to “behave normally” for users of pure ASCII.  This
+      ``String`` to "behave normally" for users of pure ASCII.  This
       point is still open for discussion.
 
       __ http://www.unicode.org/reports/tr29/#GB2
 
    2. The `Unicode Text Segmentation Specification`_ says,
-      “`do not break between regional indicator symbols`__.”  However, it also
-      says “(Sequences of more than two RI characters should be separated
-      by other characters, such as U+200B ZWSP).”  Although the
+      "`do not break between regional indicator symbols`__."  However, it also
+      says "(Sequences of more than two RI characters should be separated
+      by other characters, such as U+200B ZWSP)."  Although the
       parenthesized note probably has less official weight than the other
       admonition, breaking pairs of RI characters seems like the right
       thing for us to do given that Cocoa already forms strings with
@@ -278,7 +278,7 @@ Strings are **Locale-Agnostic**
 
 Strings neither carry their own locale information, nor provide
 behaviors that depend on a global locale setting.  Thus, for any pair
-of strings ``s1`` and ``s2``, “``s1 == s2``” yields the same result
+of strings ``s1`` and ``s2``, "``s1 == s2``" yields the same result
 regardless of system state.  Strings *do* provide a suitable
 foundation on which to build locale-aware interfaces.\ [#locales]_ 
 
@@ -316,8 +316,8 @@ Strings are Composed of ``Character``\ s
 cluster**, as specified by a default or tailored Unicode segmentation
 algorithm.  This term is `precisely defined`__ by the Unicode
 specification, but it roughly means `what the user thinks of when she
-hears “character”`__. For example, the pair of code points “LATIN
-SMALL LETTER N, COMBINING TILDE” forms a single grapheme cluster, “ñ”.
+hears "character"`__. For example, the pair of code points "LATIN
+SMALL LETTER N, COMBINING TILDE" forms a single grapheme cluster, "ñ".
 
 __ http://www.unicode.org/glossary/#grapheme_cluster
 __ http://useless-factor.blogspot.com/2007/08/unicode-implementers-guide-part-4.html
@@ -342,8 +342,8 @@ __ http://www.unicode.org/glossary/#extended_grapheme_cluster
 __ http://www.unicode.org/reports/tr29/#Default_Grapheme_Cluster_Table
 
 This segmentation offers naïve users of English, Chinese, French, and
-probably a few other languages what we think of as the “expected
-results.”  However, not every script_ can be segmented uniformly for
+probably a few other languages what we think of as the "expected
+results."  However, not every script_ can be segmented uniformly for
 all purposes.  For example, searching and collation require different
 segmentations in order to handle Indic scripts correctly.  To that
 end, strings support properties for more-specific segmentations:
@@ -386,9 +386,9 @@ Strings are **Sliceable**
 .. parsed-literal::
    |swift| s[r.start...r.end]
    `// r2 : String = "awe"`
-   |swift| s[\ :look1:`r.start...`\ ]\ :aside:`postfix slice operator means “through the end”`
+   |swift| s[\ :look1:`r.start...`\ ]\ :aside:`postfix slice operator means "through the end"`
    `// r3 : String = "awesome"`
-   |swift| s[\ :look1:`...r.start`\ ]\ :aside:`prefix slice operator means “from the beginning”`
+   |swift| s[\ :look1:`...r.start`\ ]\ :aside:`prefix slice operator means "from the beginning"`
    `// r4 : String = "Strings are "`
    |swift| :look1:`s[r]`\ :aside:`indexing with a range is the same as slicing`
    `// r5 : String = "awe"`
@@ -579,7 +579,7 @@ How Would You Design It?
     5. CodePoint substring search is just byte string search
     6. Most programs that handle 8-bit files safely can handle UTF-8 safely
     7. UTF-8 sequences sort in code point order.
-    8. UTF-8 has no “byte order.”
+    8. UTF-8 has no "byte order."
 
     __ http://research.swtch.com/2010/03/utf-8-bits-bytes-and-benefits.html
 
@@ -682,7 +682,7 @@ withRange:subrange]`` becomes ``str[subrange].doFoo(arg)``.
 
   * Deprecated Cocoa APIs are not considered
 
-  * A status of “*Remove*” below indicates a feature whose removal is
+  * A status of "*Remove*" below indicates a feature whose removal is
     anticipated.  Rationale is provided for these cases.
 
 Indexing
@@ -806,18 +806,18 @@ Comparison
      func **<=** (lhs: String, rhs: String) -> Bool
      func **>=** (lhs: String, rhs: String) -> Bool
 
-``NSString`` comparison is “literal” by default.  As the documentation
+``NSString`` comparison is "literal" by default.  As the documentation
 says of ``isEqualToString``,
 
-  “Ö” represented as the composed character sequence “O” and umlaut
-  would not compare equal to “Ö” represented as one Unicode character.
+  "Ö" represented as the composed character sequence "O" and umlaut
+  would not compare equal to "Ö" represented as one Unicode character.
 
 By contrast, Swift string's primary comparison interface uses
 Unicode's default collation_ algorithm, and is thus always
-“Unicode-correct.”  Unlike comparisons that depend on locale, it is
+"Unicode-correct."  Unlike comparisons that depend on locale, it is
 also stable across changes in system state.  However, *just like*
 ``NSString``\ 's ``isEqualToString`` and ``compare`` methods, it
-should not be expected to yield ideal (or even “proper”) results in
+should not be expected to yield ideal (or even "proper") results in
 all contexts.
 
 ---------
@@ -1084,10 +1084,10 @@ Capitalization
 
 .. Note:: ``NSString`` capitalizes the first letter of each substring
           separated by spaces, tabs, or line terminators, which is in
-          no sense “Unicode-correct.”  In most other languages that
+          no sense "Unicode-correct."  In most other languages that
           support a ``capitalize`` method, it operates only on the
           first character of the string, and capitalization-by-word is
-          named something like “``title``.”  If Swift ``String``
+          named something like "``title``."  If Swift ``String``
           supports capitalization by word, it should be
           Unicode-correct, but how we sort this particular area out is
           still **TBD**.
@@ -1712,7 +1712,7 @@ Why YAGNI
 * Derivation
 * ...
 
-.. [#agnostic] Unicode specifies default (“un-tailored”)
+.. [#agnostic] Unicode specifies default ("un-tailored")
    locale-independent collation_ and segmentation_ algorithms that
    make reasonable sense in most contexts.  Using these algorithms
    allows strings to be naturally compared and combined, generating
@@ -1748,6 +1748,6 @@ Why YAGNI
    been normalized, thus speeding up comparison operations.
 
 .. [#elements] Since ``String`` is locale-agnostic_, its elements are
-   determined using Unicode's default, “un-tailored” segmentation_
+   determined using Unicode's default, "un-tailored" segmentation_
    algorithm.
 

docs/TextFormatting.rst

@@ -21,9 +21,9 @@ Scope
 Goals
 .....
 
-* The REPL and LLDB (“debuggers”) share formatting logic
-* All types are “debug-printable” automatically
-* Making a type “printable for humans” is super-easy
+* The REPL and LLDB ("debuggers") share formatting logic
+* All types are "debug-printable" automatically
+* Making a type "printable for humans" is super-easy
 * ``toString()``-ability is a consequence of printability.
 * Customizing a type's printed representations is super-easy
 * Format variations such as numeric radix are explicit and readable
@@ -43,11 +43,11 @@ Non-Goals
   that feature.  Therefore, localization and dynamic format strings
   should be designed together, and *under this proposal* the only
   format strings are string literals containing interpolations
-  (“``\(...)``”). Cocoa programmers can still use Cocoa localization
+  ("``\(...)``"). Cocoa programmers can still use Cocoa localization
   APIs for localization jobs.
 
   In Swift, only the most common cases need to be very terse.
-  Anything “fancy” can afford to be a bit more verbose. If and when
+  Anything "fancy" can afford to be a bit more verbose. If and when
   we address localization and design a full-featured dynamic string
   formatter, it may make sense to incorporate features of ``printf``
   into the design.
@@ -68,7 +68,7 @@ printed with ``print(x)``, and can be converted to ``String`` with
 
 The simple extension story for beginners is as follows: 
 
-  “To make your type ``CustomStringConvertible``, simply declare conformance to
+  "To make your type ``CustomStringConvertible``, simply declare conformance to
   ``CustomStringConvertible``::
 
     extension Person : CustomStringConvertible {}
@@ -152,9 +152,9 @@ directly to the ``OutputStream`` for efficiency reasons,
    Producing a representation that can be consumed by the REPL
    and LLDB to produce an equivalent object is strongly encouraged
    where possible!  For example, ``String.debugFormat()`` produces
-   a representation starting and ending with “``"``”, where special
+   a representation starting and ending with "``"``", where special
    characters are escaped, etc. A ``struct Point { var x, y: Int }``
-   might be represented as “``Point(x: 3, y: 5)``”.
+   might be represented as "``Point(x: 3, y: 5)``".
 
 (Non-Debug) Printing
 ....................
@@ -348,7 +348,7 @@ an underlying stream::
 
 However, upcasing is a trivial example: many such transformations—such
 as ``trim()`` or regex replacement—are stateful, which implies some
-way of indicating “end of input” so that buffered state can be
+way of indicating "end of input" so that buffered state can be
 processed and written to the underlying stream:
 
 .. parsed-literal::
@@ -422,10 +422,10 @@ If we were willing to say that only ``class``\ es can conform to
 ``OutputStream``\ s are passed around. Then, we'd simply need a
 ``class StringStream`` for creating ``String`` representations. It
 would also make ``OutputStream`` adapters a *bit* simpler to use
-because you'd never need to “write back” explicitly onto the target
+because you'd never need to "write back" explicitly onto the target
 stream. However, stateful ``OutputStream`` adapters would still need a
 ``close()`` method, which makes a perfect place to return a copy of
-the underlying stream, which can then be “written back”:
+the underlying stream, which can then be "written back":
 
 .. parsed-literal::