diff --git a/docs/AccessControlInStdlib.rst b/docs/AccessControlInStdlib.rst index d21f91928f318..9bf32bc54a97e 100644 --- a/docs/AccessControlInStdlib.rst +++ b/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`_: diff --git a/docs/MutationModel.rst b/docs/MutationModel.rst index dae65de7431d2..8a3e802fe9b8c 100644 --- a/docs/MutationModel.rst +++ b/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 ------------------- diff --git a/docs/OptimizerDesign.md b/docs/OptimizerDesign.md index dd653dad74912..79bfb2de16311 100644 --- a/docs/OptimizerDesign.md +++ b/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". diff --git a/docs/SIL.rst b/docs/SIL.rst index cd0db6fd3f2a6..eba94d05bb030 100644 --- a/docs/SIL.rst +++ b/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 diff --git a/docs/SequencesAndCollections.rst b/docs/SequencesAndCollections.rst index f6272314b22e1..3478e89d62dee 100644 --- a/docs/SequencesAndCollections.rst +++ b/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 { diff --git a/docs/StdlibAPIGuidelines.rst b/docs/StdlibAPIGuidelines.rst index 42db44fe3abdd..230bac5ae3967 100644 --- a/docs/StdlibAPIGuidelines.rst +++ b/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` 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 diff --git a/docs/StdlibRationales.rst b/docs/StdlibRationales.rst index 02d423d4b0a6d..6b90b80d14935 100644 --- a/docs/StdlibRationales.rst +++ b/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 diff --git a/docs/StringDesign.rst b/docs/StringDesign.rst index 17d496e32d463..5e56ace9a7390 100644 --- a/docs/StringDesign.rst +++ b/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. diff --git a/docs/TextFormatting.rst b/docs/TextFormatting.rst index 6c9bedfdc8ce7..30e47ef83eb5a 100644 --- a/docs/TextFormatting.rst +++ b/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:: diff --git a/docs/proposals/CompressedMangledNames.md b/docs/proposals/CompressedMangledNames.md index 766e1beb35a2e..bc581474f99f2 100644 --- a/docs/proposals/CompressedMangledNames.md +++ b/docs/proposals/CompressedMangledNames.md @@ -76,7 +76,7 @@ obvious alternative is to use "prior knowledge". We know what are the common sub-strings that are used in Swift names. Some of the most common substrings in Swift mangled names are: - "S_S_S_S", "ollectio”, “Type”, “Index”, “erator”, “7Element", and “able". + "S_S_S_S", "ollectio", "Type", "Index", "erator", "7Element", and "able". We can use this prior knowledge to compress our mangling! @@ -114,20 +114,20 @@ number of occurrences) is encoded with a single escape character and a single index character. The table of highly repetitive substrings can only contain 61 entries (a-zA-Z0-9_, minus two escape characters). -A reference to the very frequent substrings is encoded as “Yx”, where x is the +A reference to the very frequent substrings is encoded as "Yx", where x is the character that is translated into a numeric index. This is two chars per substring. 3. The less frequently used substrings are encoded as three-character sequence. -“Zxx”, where xx is the numeric index in the large table (that can hold 61*61 +"Zxx", where xx is the numeric index in the large table (that can hold 61*61 substrings). It is obvious how to reverse this compression using the same string table used to compress the names. With this encoding scheme the name -“__TwxxV14StdlibUnittest24MinimalForwardCollection” becomes -"__TwxxJ1QYrt24J6wJ5KY9on" and the name “__TMPVs15ContiguousArray” becomes +"__TwxxV14StdlibUnittest24MinimalForwardCollection" becomes +"__TwxxJ1QYrt24J6wJ5KY9on" and the name "__TMPVs15ContiguousArray" becomes "__TMPJOSJ6lJ8G". Notice that the "_T" prefix is kept and should not be compressed because it diff --git a/docs/proposals/InoutCOWOptimization.rst b/docs/proposals/InoutCOWOptimization.rst index dc1de11c3d3c9..c784fda253786 100644 --- a/docs/proposals/InoutCOWOptimization.rst +++ b/docs/proposals/InoutCOWOptimization.rst @@ -25,8 +25,8 @@ The problem is caused as follows: x[0].mutate() - we “``subscript get``” ``x[0]`` into a temporary, mutate the - temporary, and “``subscript set``” it back into ``x[0]``. + we "``subscript get``" ``x[0]`` into a temporary, mutate the + temporary, and "``subscript set``" it back into ``x[0]``. * When the element itself is a COW type, that temporary implies a retain count of at least 2 on the element's buffer. diff --git a/docs/proposals/Inplace.rst b/docs/proposals/Inplace.rst index 3f835df5e3a40..47cc17089b1ab 100644 --- a/docs/proposals/Inplace.rst +++ b/docs/proposals/Inplace.rst @@ -424,7 +424,7 @@ fine:: foo.=advanced(10) The alternative would be to say that explicitly-written assignment methods -cannot work properly for immutable classes and “work” with reference +cannot work properly for immutable classes and "work" with reference semantics on other classes. We consider this approach indefensible, especially when one considers that operators encourage writing algorithms that can only work properly with value semantics and will diff --git a/docs/proposals/ValueSemantics.rst b/docs/proposals/ValueSemantics.rst index 8ac57b4b6eb48..5d03c19518d0b 100644 --- a/docs/proposals/ValueSemantics.rst +++ b/docs/proposals/ValueSemantics.rst @@ -25,7 +25,7 @@ Value Semantics --------------- For a type with value semantics, variable initialization, assignment, -and argument-passing (hereafter, “the big three operations”) each +and argument-passing (hereafter, "the big three operations") each create an *independently modifiable copy* of the source value that is *interchangeable with the source*. [#interchange]_ @@ -151,13 +151,13 @@ The Problem With Generics The classic Liskov principle says the semantics of operations on ``Duck``\ 's subtypes need to be consistent with those on ``Duck`` itself, -so that functions operating on ``Duck``\ s still “work” when passed a +so that functions operating on ``Duck``\ s still "work" when passed a ``Mallard``. More generally, for a function to make meaningful guarantees, the semantics of its sub-operations need to be consistent regardless of the actual argument types passed. The type of an argument passed by-value to an ordinary function is -fully constrained, so the “big three” have knowable semantics. The +fully constrained, so the "big three" have knowable semantics. The type of an ordinary argument passed by-reference is constrained by subtype polymorphism, where a (usually implicit) contract between base- and sub-types can dictate consistency. @@ -196,7 +196,7 @@ value type:: The reason the above breaks when the state is in a class instance is that the intended copy in line 1 instead creates a new reference to the same state, and the comparison in line 2 (regardless of whether we -decide ``!=`` does “identity” or “value” comparison) always succeeds. +decide ``!=`` does "identity" or "value" comparison) always succeeds. You can write a different implementation that only works on clonable classes: diff --git a/docs/proposals/rejected/ClassConstruction.rst b/docs/proposals/rejected/ClassConstruction.rst index 74452b7a1da9f..5b1ea48747c5d 100644 --- a/docs/proposals/rejected/ClassConstruction.rst +++ b/docs/proposals/rejected/ClassConstruction.rst @@ -7,7 +7,7 @@ .. warning:: This proposal was rejected, though it helped in the design of the final Swift 1 initialization model. -Objective-C's “designated initializers pattern seems at first to +Objective-C's "designated initializers pattern seems at first to create a great deal of complication. However, designated initializers are simply the only sane response to Objective-C's initialization rules, which are the root cause of the complication. @@ -116,9 +116,9 @@ Proposal ======== I suggest we define Swift initialization to be as simple and -easily-understood as possible, and avoid “interesting” interactions +easily-understood as possible, and avoid "interesting" interactions with the more complicated Objective-C initialization process. If we -do this, we can treat Objective-C base classes as “sealed and safe” +do this, we can treat Objective-C base classes as "sealed and safe" for the purpose of initialization, and help programmers reason effectively about initialization and their class invariants. @@ -133,7 +133,7 @@ Here are the proposed rules: Objective-C. * ``self.init(…)`` calls in Swift never dispatch virtually. We have a - safe model for “virtual initialization:” ``init`` methods can call + safe model for "virtual initialization:" ``init`` methods can call overridable methods after all instance variables and superclasses are initialized. Allowing *virtual* constructor delegation would undermine that safety. diff --git a/docs/proposals/rejected/Clonable.rst b/docs/proposals/rejected/Clonable.rst index 949ecf93cb883..39bf2c5d08a41 100644 --- a/docs/proposals/rejected/Clonable.rst +++ b/docs/proposals/rejected/Clonable.rst @@ -15,7 +15,7 @@ language-level copying mechanism for classes. **Abstract:** to better support the creation of value types, we -propose a “magic” ``Clonable`` protocol and an annotation for describing +propose a "magic" ``Clonable`` protocol and an annotation for describing which instance variables should be cloned when a type is copied. This proposal **augments revision 1** of the Clonable proposal with our rationale for dropping our support for ``val`` and ``ref``, a @@ -65,7 +65,7 @@ automatic, if we add that feature) forwarding. By dropping ``val`` we also lose some terseness aggregating ``class`` contents into ``struct``\ s. However, since ``ref`` is being dropped -there's less call for a symmetric ``val``. The extra “cruft” that +there's less call for a symmetric ``val``. The extra "cruft" that ``[clone]`` adds actually seems appropriate when viewed as a special bridge for ``class`` types, and less like a penalty against value types. @@ -125,7 +125,7 @@ variables marked ``[clone]``:: var somethingIJustReferTo : Bar } -When a ``Baz`` is copied by any of the “big three” operations (variable +When a ``Baz`` is copied by any of the "big three" operations (variable initialization, assignment, or function argument passing), even as part of a larger ``struct``, its ``[clone]`` member is ``clone()``\ d. Because ``Foo`` itself has a ``[clone]`` member, that is ``clone()``\ d diff --git a/docs/proposals/rejected/Constructors.rst b/docs/proposals/rejected/Constructors.rst index fc69a38f4b6ab..c88b9b7802571 100644 --- a/docs/proposals/rejected/Constructors.rst +++ b/docs/proposals/rejected/Constructors.rst @@ -461,11 +461,11 @@ zero-argument selector with no trailing colon, e.g.,:: maps to the selector ``initToMemory``. -This mapping is reversible: given a selector in the “init” family, -i.e., where the first word is “init”, we split the selector into its +This mapping is reversible: given a selector in the "init" family, +i.e., where the first word is "init", we split the selector into its various pieces at the colons: -* For the first piece, we remove the “init” and then lowercase the +* For the first piece, we remove the "init" and then lowercase the next character *unless* the second character is also uppercase. This becomes the name of the first parameter to the constructor. If this string is non-empty and the selector is a zero-argument selector diff --git a/docs/proposals/valref.rst b/docs/proposals/valref.rst index a76bfae0282e3..04f9dfe18fb34 100644 --- a/docs/proposals/valref.rst +++ b/docs/proposals/valref.rst @@ -29,15 +29,15 @@ Introduction Until recently, Swift's support for value semantics outside trivial types like scalars and immutable strings has been weak. While the -recent ``Clonable`` proposal makes new things possible in the “safe” +recent ``Clonable`` proposal makes new things possible in the "safe" zone, it leaves the language syntactically and semantically lumpy, keeping interactions between value and reference types firmly outside -the “easy” zone and failing to address the issue of generic +the "easy" zone and failing to address the issue of generic programming. This proposal builds on the ``Clonable`` proposal to create a more uniform, flexible, and interoperable type system while solving the -generic programming problem and expanding the “easy” zone. +generic programming problem and expanding the "easy" zone. General Description =================== @@ -68,8 +68,8 @@ When applied to ``class`` types, "copy" means to call the ``clone()`` method, which is generated by the compiler when the user has explicitly declared conformance to the ``Clonable`` protocol. -When we refer to variables being “declared ``val``” or “declared -``ref``”, we mean to include the case of equivalent declarations using +When we refer to variables being "declared ``val``" or "declared +``ref``", we mean to include the case of equivalent declarations using ``var`` that request the default semantics for the type. Unless otherwise specified, we discuss implementation details such as @@ -425,7 +425,7 @@ How This Design Improves Swift matters. 4. We move the cases where values and references interact much closer - to, and arguably into, the “easy” zone. + to, and arguably into, the "easy" zone. How This Design Beats Rust/C++/C#/etc. ====================================== @@ -437,7 +437,7 @@ How This Design Beats Rust/C++/C#/etc. rooting`__, etc. By contrast, there's a path to learning swift that postpones the ``val``\ /``ref`` distinction, and that's pretty much *all* one must learn to have a complete understanding of the object - model in the “easy” and “safe” zones. + model in the "easy" and "safe" zones. __ http://static.rust-lang.org/doc/tutorial.html#boxes-and-pointers __ http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html#named-lifetimes @@ -560,7 +560,7 @@ example: There's always the dreaded ``auto``. * Should we drop ``let``\ /``var``\ /``auto`` for ivars, because it - “just feels wrong” there? + "just feels wrong" there? * ``ref`` is spelled like ``[inout]``, but they mean very different things @@ -569,7 +569,7 @@ example: ``[inout]``. * Should we spell ``[inout]`` differently? I think at a high level - it means something like “``[rebind]`` the name to a new value.” + it means something like "``[rebind]`` the name to a new value." * Do we want to consider replacing ``struct`` and/or ``class`` with new names such as ``valtype`` and ``reftype``? We don't love those