@@ -92,7 +92,7 @@ the ownership system from an implementation detail to a more
92
92
visible aspect of the language. They are also somewhat
93
93
inseparable, for reasons we'll explain, although of course they
94
94
can be prioritized differently. For these reasons, we will
95
- talk about them as a cohensive feature called "ownership".
95
+ talk about them as a cohesive feature called "ownership".
96
96
97
97
### A bit more detail
98
98
@@ -118,7 +118,7 @@ arbitrary function will use its arguments; it just falls
118
118
back on a default rule for whether to pass ownership of
119
119
the value. When that default rule is wrong, the program
120
120
will end up making extra copies at runtime. So one simple
121
- thing we can do is allow programs to be more explicit at
121
+ thing we can do is to allow programs to be more explicit at
122
122
certain points about whether they need ownership or not.
123
123
124
124
That closely dovetails with the desire to support non-copyable
@@ -311,7 +311,7 @@ A *variable* is the semantics concept of a unique place in
311
311
memory that stores a value. It's not necessarily mutable, at least
312
312
as we're using it in this document. Variables are usually created for
313
313
storage declarations, but they can also be created dynamically in
314
- raw memory, e.g. using UnsafeRawPointer. A variable always has a
314
+ raw memory, e.g. using ` UnsafeRawPointer ` . A variable always has a
315
315
specific type. It also has a * lifetime* , i.e. a point in the language
316
316
semantics where it comes into existence and a point (or several)
317
317
where it is destroyed.
@@ -725,7 +725,7 @@ use static enforcement for some class instance properties.
725
725
726
726
Undefined enforcement means that conflicts are not detected
727
727
either statically or dynamically, and instead simply have
728
- undefined behavior. This is not a desireable mechanism
728
+ undefined behavior. This is not a desirable mechanism
729
729
for ordinary code given Swift's "safe by default" design,
730
730
but it's the only real choice for things like unsafe pointers.
731
731
@@ -747,7 +747,7 @@ not to escape. The following principles apply:
747
747
- If a closure ` C ` potentially escapes, then for any variable
748
748
` V ` captured by ` C ` , all accesses to ` V ` potentially executed
749
749
after a potential escape (including the accesses within ` C `
750
- itself) must use dynamic enforcement unless all such acesses
750
+ itself) must use dynamic enforcement unless all such accesses
751
751
are reads.
752
752
753
753
- If a closure ` C ` does not escape a function, then its
@@ -797,7 +797,7 @@ additional semantic concerns.
797
797
A shared value can be used in the scope that binds it
798
798
just like an ordinary parameter or ` let ` binding.
799
799
If the shared value is used in a place that requires
800
- ownership, Swift will simply implicitly copy the value —
800
+ ownership, Swift will simply implicitly copy the value --
801
801
again, just like an ordinary parameter or ` let ` binding.
802
802
803
803
#### Limitations of shared values
@@ -819,7 +819,7 @@ born from a trio of concerns:
819
819
- We have to scope this proposal to something that can
820
820
conceivably be implemented in the coming months. We expect this
821
821
proposal to yield major benefits to the language and its
822
- implementaton , but it is already quite broad and aggressive.
822
+ implementation , but it is already quite broad and aggressive.
823
823
First-class ephemerals would add enough complexity to the
824
824
implementation and design that they are clearly out of scope.
825
825
Furthermore, the remaining language-design questions are
@@ -861,7 +861,7 @@ born from a trio of concerns:
861
861
lexical and maintains the ability to run arbitrary code
862
862
at the end of an access. Imagine what it would take to
863
863
implement a loop that added these temporary mutable
864
- references to an array — each iteration of the loop would
864
+ references to an array -- each iteration of the loop would
865
865
have to be able to queue up arbitrary code to run as a clean-up
866
866
when the function was finished with the array. This would
867
867
hardly be a low-cost abstraction! A more Rust-like
@@ -1078,7 +1078,7 @@ A non-mutating iteration simply visits each of the elements
1078
1078
in the collection, leaving it intact and unmodified. We have
1079
1079
no reason to copy the elements; the iteration variable can
1080
1080
simply be bound to a shared value. This is a ` nonmutating `
1081
- operaton on ` Collection ` .
1081
+ operation on ` Collection ` .
1082
1082
1083
1083
This can be explicitly requested by declaring the iteration
1084
1084
variable ` shared ` :
@@ -1285,7 +1285,7 @@ value is returned. This is useful for several reasons:
1285
1285
reference, that storage is normally accessed for the duration
1286
1286
of the call. The programmer can suppress this and force the
1287
1287
copy to complete before the call by calling ` copy ` on the
1288
- storage reference before
1288
+ storage reference before.
1289
1289
1290
1290
- It is necessary for types that have suppressed implicit
1291
1291
copies. See the section below on non-copyable types.
@@ -1402,7 +1402,7 @@ default.
1402
1402
1403
1403
The logical solution is to maintain the default assumption
1404
1404
that all types are copyable, and then allow select contexts
1405
- to turn that assumption off. We will cause these contexts
1405
+ to turn that assumption off. We will call these contexts
1406
1406
` moveonly ` contexts. All contexts lexically nested within
1407
1407
a ` moveonly ` context are also implicitly ` moveonly ` .
1408
1408
0 commit comments