averello/swift-mirror
1
0
Fork 0
mirror of https://github.com/apple/swift.git synced 2025-12-14 20:36:38 +01:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
practicalswift
2017-01-08 15:22:42 +01:00
parent 74d03b9dd9
commit 3918d9d251
31 changed files with 128 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
CHANGELOG.md
View File

@@ -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() { ... }
}
```

10
benchmark/README.md
View File

@@ -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.

4
docs/AccessControl.rst
View File

@@ -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

2
docs/AccessControlInStdlib.rst
View File

@@ -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.

6
docs/Arrays.rst
View File

@@ -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

6
docs/GenericsManifesto.md
View File

@@ -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

6
docs/GitWorkflows.rst
View File

@@ -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.

2
docs/InitializerProblems.rst
View File

@@ -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 {

10
docs/LibraryEvolution.rst
View File

@@ -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``

2
docs/MutationModel.rst
View File

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

20
docs/PatternMatching.rst
View File

@@ -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,17 +285,17 @@ 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
@@ -303,9 +303,9 @@ 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.

20
docs/SequencesAndCollections.rst
View File

@@ -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

24
docs/StringDesign.rst
View File

@@ -194,7 +194,7 @@ Strings are **Mutable**
The ability to change a string's value might not be worth noting
except that *some languages make all strings immutable*, as a way
of working around problems that Swift has defined away—by making
of working around problems that Swift has defined away--by making
strings pure values (see below).
.. parsed-literal::
@@ -231,13 +231,13 @@ passes you a string *you own it*. Nobody can change a string value
|swift| var c = Cave()
`// c: Cave = <Cave instance>`
|swift| s = "Hey"
|swift| var t = :look1:`c.say(s)`\ :aside:`this call can't change s…`
|swift| var t = :look1:`c.say(s)`\ :aside:`this call can't change s...`
`// t: String = "HeyHey"`
|swift| s
`// s: String =` :look:`"Hey"`\ :aside:`…and it doesn't.`
|swift| :look1:`t.addEcho()`\ :aside:`this call can't change c.lastSound…`
`// s: String =` :look:`"Hey"`\ :aside:`...and it doesn't.`
|swift| :look1:`t.addEcho()`\ :aside:`this call can't change c.lastSound...`
|swift| [s, c.lastSound, t]
`// r0: [String] = ["Hey",` :look:`"HeyHey"`\ :aside:`…and it doesn't.`\ `, "HeyHeyHeyHey"]`
`// r0: [String] = ["Hey",` :look:`"HeyHey"`\ :aside:`...and it doesn't.`\ `, "HeyHeyHeyHey"]`
Strings are **Unicode-Aware**
-----------------------------
@@ -320,7 +320,7 @@ Strings are **Containers**
|swift| var s = "Strings are awesome"
`// s : String = "Strings are awesome"`
|swift| var r = s.find("awe")
`// r : Range<StringIndex> = <"…are a̲w̲e̲some">`
`// r : Range<StringIndex> = <"...are a̲w̲e̲some">`
|swift| s[r.start]
`// r0 : Character =` :look:`Character("a")`\ :aside:`String elements have type Character (see below)`
@@ -516,8 +516,8 @@ Why a Built-In String Type?
"value semantics" in place of "C++ semantics". I know that is what
you meant, but we need to tread carefully in the final document.
``NSString`` and ``NSMutableString``\ —the string types provided by
Cocoa—are full-featured classes with high-level functionality for
``NSString`` and ``NSMutableString``\ --the string types provided by
Cocoa--are full-featured classes with high-level functionality for
writing fully-localized applications. They have served Apple
programmers well; so, why does Swift have its own string type?
@@ -887,7 +887,7 @@ all contexts.
:``NSAnchoredSearch``: Not applicable to whole-string comparisons
:``NSNumericSearch``: While it's legitimate to defer this
functionality to Cocoa, it's (probably—see
functionality to Cocoa, it's (probably--see
<rdar://problem/14724804>) locale-independent and
easy enough to implement in Swift. TBD_
:``NSDiacriticInsensitiveSearch``: Ditto; TBD_
@@ -916,7 +916,7 @@ Searching
.. Sidebar:: Rationale
Modern languages (Java, C#, Python, Ruby…) have standardized on
Modern languages (Java, C#, Python, Ruby...) have standardized on
variants of ``startsWith``/\ ``endsWith``. There's no reason Swift
should deviate from de-facto industry standards here.
@@ -1012,7 +1012,7 @@ Dynamic Formatting
.. parsed-literal::
\- (NSString \*)\ **stringByAppendingFormat:**\ (NSString \*)format, ... NS_FORMAT_FUNCTION(1,2);
:Swift: *Not directly provided*\ —see the *Swift formatting proposal*
:Swift: *Not directly provided*\ --see the *Swift formatting proposal*
Extracting Numeric Values
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1026,7 +1026,7 @@ Extracting Numeric Values
\- (long long)longLongValue;
\- (BOOL)boolValue;
:Swift: Not in ``String``\ —It is up to other types to provide their
:Swift: Not in ``String``\ --It is up to other types to provide their
conversions to and from String. See also this `rationale`__
__ extending_

14
docs/TextFormatting.rst
View File

@@ -90,14 +90,14 @@ Formatting Variants
-------------------
``CustomStringConvertible`` types with parameterized textual representations
(e.g. number types) *additionally* support a ``format(…)`` method
(e.g. number types) *additionally* support a ``format(...)`` method
parameterized according to that type's axes of variability::
print(offset)
print(offset.format()) // equivalent to previous line
print(offset.format(radix: 16, width: 5, precision: 3))
Although ``format(…)`` is intended to provide the most general
Although ``format(...)`` is intended to provide the most general
interface, specialized formatting interfaces are also possible::
print(offset.hex())
@@ -256,7 +256,7 @@ Extended Formatting Example
The following code is a scaled-down version of the formatting code
used for ``Int``. It represents an example of how a relatively
complicated ``format(…)`` might be written::
complicated ``format(...)`` might be written::
protocol CustomStringConvertibleInteger
: ExpressibleByIntegerLiteral, Comparable, SignedNumber, CustomStringConvertible {
@@ -346,8 +346,8 @@ an underlying stream::
var base: UnderlyingStream
}
However, upcasing is a trivial example: many such transformations—such
as ``trim()`` or regex replacement—are stateful, which implies some
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
processed and written to the underlying stream:
@@ -396,7 +396,7 @@ and, finally, we'd be able to write:
The complexity of this back-and-forth adapter dance is daunting, and
might well be better handled in the language once we have some formal
model—such as coroutines—of inversion-of-control. We think it makes
model--such as coroutines--of inversion-of-control. We think it makes
more sense to build the important transformations directly into
``format()`` methods, allowing, e.g.:
@@ -450,7 +450,7 @@ to tip the balance in favor of the current design.
--------
.. [#format] Whether ``format(…)`` is to be a real protocol or merely
.. [#format] Whether ``format(...)`` is to be a real protocol or merely
an ad-hoc convention is TBD. So far, there's no obvious use for a
generic ``format`` with arguments that depend on the type being
formatted, so an ad-hoc convention would be just fine.

20
docs/archive/Resilience.rst
View File

@@ -27,7 +27,7 @@ behavior of our implementations would work against these goals.
Almost all languages provide some amount of abstraction of implementation. For
example, functions are usually opaque data types which fully abstract away the
exact sequence of operations performed. Similarly, adding a new field to a C
struct does not break programs which refer to a different field — those programs
struct does not break programs which refer to a different field -- those programs
may need to be recompiled, but once recompiled, they should continue to
work. (This would not necessarily be true if, say, fields were accessed by index
rather than by name.)
@@ -517,7 +517,7 @@ of this: [born_unchanging] for things that are universally non-resilient,
Global functions always export a maximally-resilient entrypoint. If there exist
any [fragile] arguments, and there do not exist any resilient arguments, they
also export a [fragile] copy. Callers do… something? Have to know what they're
also export a [fragile] copy. Callers do... something? Have to know what they're
deploying against, I guess.
Want some concrete representation for [ref] arguments.
@@ -611,7 +611,7 @@ Break it down by types of declarations.
* typealias has no resilience
* struct — the set/order of fields can change — means size/alignment, layout,
* struct -- the set/order of fields can change -- means size/alignment, layout,
copy/destruction semantics, etc. can all change
* fields - direct access vs. getter/setter
@@ -620,27 +620,27 @@ Break it down by types of declarations.
* types - as if top level
* class — same as a structs, plus
* class -- same as a structs, plus
* base classes — can't completely remove a base class (breaks interface), but
* base classes -- can't completely remove a base class (breaks interface), but
can introduce a new intermediate base
* virtual dispatch — table vs. dictionary, devirtualization (to which
* virtual dispatch -- table vs. dictionary, devirtualization (to which
decl?). Some amount of table lookup can be done as static vs. dynamic offsets
* funcs — inlineability
* funcs -- inlineability
* vars — direct access vs. getter/setter. Direct accesses for types that aren't
* vars -- direct access vs. getter/setter. Direct accesses for types that aren't
inherently fragile need to be indirected because they may need to be
dynamically allocated. In general, might be actor-local, this is for when the
model does say "global variable".
* extensions of classes — like class. Fields are always side-allocated if we're
* extensions of classes -- like class. Fields are always side-allocated if we're
extending a class not defined in this component (w/i domain?). Making a class
fragile is also a promise not to add more fields in extensions in this
component; probably need a way to force a side-table.
* protocols — can't remove/change existing methods, but can add defaulted
* protocols -- can't remove/change existing methods, but can add defaulted
methods. Doing this resiliently requires load-time checking. vtable for
non-defaulted methods, ? for rest?

2
docs/proposals/CPointerInteropLanguageModel.rst
View File

@@ -3,7 +3,7 @@
We have a pretty good user model for C pointer interop now, but the language
model still needs improvement. Building the user model on top of implicit
conversions has a number of undesirable side effects. We end up with a mess of
pointer types—the intended user-facing, one-word pointer types
pointer types--the intended user-facing, one-word pointer types
``UnsafeMutablePointer`` and ``OpaquePointer``, which expose a full pointer-ish API
and are naturally ABI-compatible with C pointers; and the bridging pointer
types, ``ObjCMutablePointer``, ``CMutablePointer``, ``CConstPointer``,

4
docs/proposals/InitializerInheritance.rst
View File

@@ -30,7 +30,7 @@ class and its superclasses.
There are three kinds of delegation:
* **super**: runs an initializer belonging to a superclass (in ObjC,
``[super init…]``; in Swift, ``super.init(...)``).
``[super init...]``; in Swift, ``super.init(...)``).
* **peer**: runs an initializer belonging to the current class (ObjC
does not have syntax for this, although it is supported by the
@@ -38,7 +38,7 @@ There are three kinds of delegation:
* **dispatched**: given a signature, runs the initializer with that
signature that is either defined or inherited by the most-derived
class (in ObjC, ``[self init…]``; not currently supported by Swift)
class (in ObjC, ``[self init...]``; not currently supported by Swift)
We can also distinguish two ways to originally invoke an initializer:

20
docs/proposals/Inplace.rst
View File

@@ -170,9 +170,9 @@ We propose to allow method pairs of the form:
.. parsed-literal::
extension **X** {
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **X**
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **X**
func **=**\ *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **Void**
func **=**\ *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **Void**
}
The second ``=f`` method is known as an **assignment method** [#getset]_.
@@ -257,7 +257,7 @@ Given an ordinary method of a type ``X``:
.. parsed-literal::
extension **X** {
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **X**
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **X**
}
if there is no corresponding *assignment method* in ``X`` with the signature
@@ -265,20 +265,20 @@ if there is no corresponding *assignment method* in ``X`` with the signature
.. parsed-literal::
extension **X** {
func *=f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **Void**
func *=f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **Void**
}
we can compile the statement
.. parsed-literal::
x\ **.=**\ *f*\ (a₀, p₁: a₁, p₂: a₂, …p\ *n*: a\ *n*)
x\ **.=**\ *f*\ (a₀, p₁: a₁, p₂: a₂, ...p\ *n*: a\ *n*)
as though it were written:
.. parsed-literal::
x **= x.**\ *f*\ (a₀, p₁: a₁, p₂: a₂, …p\ *n*: a\ *n*)
x **= x.**\ *f*\ (a₀, p₁: a₁, p₂: a₂, ...p\ *n*: a\ *n*)
Generating the Non-Mutating Form
--------------------------------
@@ -288,7 +288,7 @@ Given an *assignment method* of a value type ``X``:
.. parsed-literal::
extension **X** {
func *=f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **Void**
func *=f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **Void**
}
if there is no method in ``X`` with the signature
@@ -296,14 +296,14 @@ if there is no method in ``X`` with the signature
.. parsed-literal::
extension **X** {
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, …p\ *n*: T\ *n*) -> **X**
func *f*\ (p₀: T₀, p₁: T₁, p₂: T₂, ...p\ *n*: T\ *n*) -> **X**
}
we can compile the expression
.. parsed-literal::
**x.**\ *f*\ (a₀, p₁: a₁, p₂: a₂, …p\ *n*: a\ *n*)
**x.**\ *f*\ (a₀, p₁: a₁, p₂: a₂, ...p\ *n*: a\ *n*)
as though it were written:
@@ -311,7 +311,7 @@ as though it were written:
{
(var y: X) -> X in
y\ **.=**\ *f*\ (a₀, p₁: a₁, p₂: a₂, …p\ *n*: a\ *n*)
y\ **.=**\ *f*\ (a₀, p₁: a₁, p₂: a₂, ...p\ *n*: a\ *n*)
return y
}(x)

22
docs/proposals/RemoteMirrors.rst
View File

@@ -50,7 +50,7 @@ While this should have zero runtime overhead when not in use, it is OK if
introspection requires some additional computation, especially if it can be
front-loaded or memoized.
It is OK if in rare cases the metadata is not precise — for some allocations,
It is OK if in rare cases the metadata is not precise -- for some allocations,
we might not be able to figure out the runtime type of the contained value.
Also we will not attempt to verify the "roots" of the object graph by walking
the stack for pointers.
@@ -107,7 +107,7 @@ Opaque value buffers
These come up when a value is too large to fit inside of an existential's
inline storage, for example. They do not have a header, so we will not attempt
to introspect them at first — eventually, we could identify pointers to buffers
to introspect them at first -- eventually, we could identify pointers to buffers
where the existential is itself inside of a heap-allocated object.
Existing metadata
@@ -134,8 +134,8 @@ several strategies depending on the type being referenced. For concrete
non-generic types, a direct call to a lazy accessor can be generated. For bound
generic types T<P1, ..., Pn>, we recursively emit metadata references for the
generic parameters Pn, then call the getter for the bound type T. For
archetypes — that is, generic type parameters which are free variables in the
function body being compiled — the metadata is passed in as a value, so the
archetypes -- that is, generic type parameters which are free variables in the
function body being compiled -- the metadata is passed in as a value, so the
compiler simply emits a copy of that.
Generic type metadata tells us the size of each heap allocation, but does not
@@ -202,8 +202,8 @@ Similarly, we can think of the field type access function as an operation F(T,
S) which returns the types of the fields of T, with T again fixed at compile
time.
What we really want here is to build an "interpreter" — or really, a parser for
a simple serialized graph — which understands how to parse uninstantiated
What we really want here is to build an "interpreter" -- or really, a parser for
a simple serialized graph -- which understands how to parse uninstantiated
generic metadata, keep track of substitutions, and calculate field offsets,
sizes, and locations of references.
@@ -241,7 +241,7 @@ to identify heap references therein, and the full type for reflection. The
former could be retained while the latter could be stripped out in certain
builds.
We already have a very similar encoding — parameter type mangling in SIL. It
We already have a very similar encoding -- parameter type mangling in SIL. It
would be good to re-use this encoding, but for completeness, the full format of
a type reference is described below:
@@ -281,7 +281,7 @@ a type reference is described below:
#. **A metatype.** This consists of:
- (optional) a type reference to the instance type
- there's no required information — a metatype is always a single pointer to
- there's no required information -- a metatype is always a single pointer to
a heap object which itself does not reference any other heap objects.
#. **An existential metatype.** This consists of:
@@ -294,7 +294,7 @@ a type reference is described below:
identifiable by an index here (and once we add nested generic types, a depth).
You can visualize type references as if they are written in an S-expression
format — but in reality, it would be serialized in a compact binary form:
format -- but in reality, it would be serialized in a compact binary form:
::
@@ -373,7 +373,7 @@ tools.
case Strong, Weak, Unowned
// the field is an opaque binary blob, contents unknown.
case Opaque
// the field is a value type — look inside recursively.
// the field is a value type -- look inside recursively.
case ValueType(indirect field: FieldDescriptor)
}
@@ -386,7 +386,7 @@ tools.
func instantiateSymbolicType(_ ref: SymbolicTypeReference) -> [FieldTypeDescriptor]
Field type metadata can have circular references — for example, consider two
Field type metadata can have circular references -- for example, consider two
classes which contain optionals of each other. In order to calculate field
offsets correctly, we need to break cycles when we know something is a class
type, and use a work-list algorithm instead of unbounded recursion to ensure

2
docs/proposals/ValueSemantics.rst
View File

@@ -282,7 +282,7 @@ The Role of Moves
=================
Further complicating matters is the fact that the big three operations
can be—and often are—combined in ways that mask the value/reference
can be--and often are--combined in ways that mask the value/reference
distinction. In fact both of the following must be present in order
to observe a difference in behavior:

12
docs/proposals/archive/MemoryAndConcurrencyModel.rst
View File

@@ -177,16 +177,16 @@ With the basic approach above, you can only perform actions on actors that are
built into the actor. For example, if you had an actor with two methods::
actor MyActor {
func foo() {…}
func bar() {…}
func getvalue() -> double {… }
func foo() {...}
func bar() {...}
func getvalue() -> double {... }
}
Then there is no way to perform a composite operation that needs to "atomically"
perform foo() and bar() without any other operations getting in between. If you
had code like this::
var a : MyActor = …
var a : MyActor = ...
a.foo()
a.bar()
@@ -196,7 +196,7 @@ wouldn't be run in between them. To handle this, the async block structure can
be used to submit a sequence of code that is atomically run in the actor's
context, e.g.::
var a : MyActor = …
var a : MyActor = ...
async a {
a.foo()
a.bar()
@@ -206,7 +206,7 @@ This conceptually submits a closure to run in the context of the actor. If you
look at it this way, an async message send is conceptually equivalent to an
async block. As such, the original example was equivalent to::
var a : MyActor = …
var a : MyActor = ...
async a { a.foo() }
async a { a.bar() }

2
docs/proposals/archive/ProgramStructureAndCompilationModel.rst
View File

@@ -111,7 +111,7 @@ Components are explicitly declared, and these declarations can include:
"I depend on swift standard libs 1.4 or later"
* a list of subcomponents that contribute to the component: "mac os consists of
appkit, coredata, …"
appkit, coredata, ..."
* a list of resource files and other stuff that makes up the framework

2
docs/proposals/rejected/ClassConstruction.rst
View File

@@ -132,7 +132,7 @@ Here are the proposed rules:
default, part of the public interface of a subclass defined in
Objective-C.
* ``self.init(…)`` calls in Swift never dispatch virtually. We have a
* ``self.init(...)`` calls in Swift never dispatch virtually. We have a
safe model for "virtual initialization:" ``init`` methods can call
overridable methods after all instance variables and superclasses
are initialized. Allowing *virtual* constructor delegation would

2
docs/proposals/rejected/Clonable.rst
View File

@@ -76,7 +76,7 @@ Generics
There is actually a straightforward programming model for generics.
If you want to design a generic component where a type parameter ``T``
binds to both ``class``\ es and non-``class`` types, you can view
``T`` as a value type where—as with C pointers—the value is the
``T`` as a value type where--as with C pointers--the value is the
reference rather than the object being referred to.
Of course, if ``T`` is only supposed to bind to ``class``\ es, a

6
docs/proposals/valref.rst
View File

@@ -12,8 +12,8 @@
:Date: 2013-03-15
**Abstract:** We propose a system that offers first-class support for
both value and reference semantics. By allowing—but not
requiring—(instance) variables, function parameters, and generic
both value and reference semantics. By allowing--but not
requiring--(instance) variables, function parameters, and generic
constraints to be declared as ``val`` or ``ref``, we offer users the
ability to nail down semantics to the desired degree without
compromising ease of use.
@@ -220,7 +220,7 @@ and has value semantics::
case Cons(car:T, cdr:List<T>)
}
// A list node with reference semantics—copying the node creates a node
// A list node with reference semantics--copying the node creates a node
// that shares structure with the tail of the list
union Node<T> {
case Nil()

2
lib/SILGen/SILGenConvert.cpp
View File

@@ -237,7 +237,7 @@ ManagedValue SILGenFunction::emitUncheckedGetOptionalValueFrom(SILLocation loc,
ManagedValue payload;
// Take the payload from the optional. Cheat a bit in the +0
// case—UncheckedTakeEnumData will never actually invalidate an Optional enum
// case--UncheckedTakeEnumData will never actually invalidate an Optional enum
// value.
SILValue payloadVal;
if (!addrOrValue.getType().isAddress()) {

4
stdlib/public/SDK/Foundation/NSDictionary.swift
View File

@@ -205,8 +205,8 @@ extension NSDictionary {
/// Initializes a newly allocated dictionary and adds to it objects from
/// another given dictionary.
///
/// - Returns: An initialized dictionary—which might be different
/// than the original receiver—containing the keys and values
/// - Returns: An initialized dictionary--which might be different
/// than the original receiver--containing the keys and values
/// found in `otherDictionary`.
@objc(_swiftInitWithDictionary_NSDictionary:)
public convenience init(dictionary otherDictionary: NSDictionary) {

2
stdlib/public/SDK/Foundation/TimeZone.swift
View File

@@ -87,7 +87,7 @@ public struct TimeZone : Hashable, Equatable, ReferenceConvertible {
/// Returns a time zone identified by a given abbreviation.
///
/// In general, you are discouraged from using abbreviations except for unique instances such as "GMT". Time Zone abbreviations are not standardized and so a given abbreviation may have multiple meanings—for example, "EST" refers to Eastern Time in both the United States and Australia
/// In general, you are discouraged from using abbreviations except for unique instances such as "GMT". Time Zone abbreviations are not standardized and so a given abbreviation may have multiple meanings--for example, "EST" refers to Eastern Time in both the United States and Australia
///
/// - parameter abbreviation: The abbreviation for the time zone.
/// - returns: A time zone identified by abbreviation determined by resolving the abbreviation to an identifier using the abbreviation dictionary and then returning the time zone for that identifier. Returns `nil` if there is no match for abbreviation.

4
stdlib/public/core/Integers.swift.gyb
View File

@@ -81,8 +81,8 @@ extension ExpressibleByIntegerLiteral
//===--- Arithmetic -------------------------------------------------------===//
//===----------------------------------------------------------------------===//
/// Declares methods backing binary arithmetic operators—such as `+`, `-` and
/// `*`—and their mutating counterparts.
/// Declares methods backing binary arithmetic operators--such as `+`, `-` and
/// `*`--and their mutating counterparts.
///
/// It provides a suitable basis for arithmetic on scalars such as integers and
/// floating point numbers.

6
stdlib/public/core/Unicode.swift
View File

@@ -280,7 +280,7 @@ public struct UTF8 : UnicodeCodec {
static func _decodeOne(_ buffer: UInt32) -> (result: UInt32?, length: UInt8) {
// Note the buffer is read least significant byte first: [ #3 #2 #1 #0 ].
if buffer & 0x80 == 0 { // 1-byte sequence (ASCII), buffer: [ … … … CU0 ].
if buffer & 0x80 == 0 { // 1-byte sequence (ASCII), buffer: [ ... ... ... CU0 ].
let value = buffer & 0xff
return (value, 1)
}
@@ -304,7 +304,7 @@ public struct UTF8 : UnicodeCodec {
let bit1 = (lut1 >> index) & 1
switch (bit1, bit0) {
case (0, 0): // 2-byte sequence, buffer: [ … … CU1 CU0 ].
case (0, 0): // 2-byte sequence, buffer: [ ... ... CU1 CU0 ].
// Require 10xx xxxx 110x xxxx.
if _slowPath(buffer & 0xc0e0 != 0x80c0) { return (nil, 1) }
// Disallow xxxx xxxx xxx0 000x (<= 7 bits case).
@@ -314,7 +314,7 @@ public struct UTF8 : UnicodeCodec {
| (buffer & 0x001f) << 6
return (value, 2)
case (0, 1): // 3-byte sequence, buffer: [ … CU2 CU1 CU0 ].
case (0, 1): // 3-byte sequence, buffer: [ ... CU2 CU1 CU0 ].
// Disallow xxxx xxxx xx0x xxxx xxxx 0000 (<= 11 bits case).
if _slowPath(buffer & 0x00200f == 0x000000) { return (nil, 1) }
// Disallow xxxx xxxx xx1x xxxx xxxx 1101 (surrogate code points).

2
stdlib/public/core/UnsafeRawBufferPointer.swift.gyb
View File

@@ -468,7 +468,7 @@ public struct Unsafe${Mutable}RawBufferPointer
to: base + count - elementStride + 1,
by: elementStride
) {
// underflow is permitted – e.g. a sequence into
// underflow is permitted -- e.g. a sequence into
// the spare capacity of an Array buffer
guard let x = it.next() else { break }
p.initializeMemory(as: S.Iterator.Element.self, to: x)