You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -27,7 +27,7 @@ Many standard library container types can provide direct access to modify their
27
27
28
28
These functions have a few different drawbacks, most prominently their reliance on unsafe types, which makes them unpalatable in security-conscious environments. We continue addressing these issues with `MutableSpan` and `MutableRawSpan`, new non-copyable and non-escapable types that manage respectively mutations of typed and untyped memory.
29
29
30
-
In addition to the new types, we will propose adding new API some standard library types to take advantage of `MutableSpan` and `MutableRawSpan`.
30
+
In addition to the new types, we will propose adding new API to some standard library types to take advantage of `MutableSpan` and `MutableRawSpan`.
31
31
32
32
## Proposed solution
33
33
@@ -53,7 +53,7 @@ A `MutableSpan` provided by a container represents a mutation of that container,
53
53
The standard library will provide `mutableSpan` computed properties. These return a new lifetime-dependent `MutableSpan` instance, and that `MutableSpan` represents a mutation of the instance that provided it. The `mutableSpan` computed properties are the safe and composable replacements for the existing `withUnsafeMutableBufferPointer` closure-taking functions. For example,
54
54
55
55
```swift
56
-
func(_ array:inoutArray<Int>) {
56
+
funcexample(_array: inoutArray<Int>) {
57
57
var ms = array.mutableSpan
58
58
modify(&ms) // call function that mutates a MutableSpan<Int>
59
59
// array.append(2) // attempt to modify `array` would be an error here
@@ -532,7 +532,7 @@ extension MutableRawSpan {
532
532
) throws(E) -> Result
533
533
}
534
534
```
535
-
These functions use a closure to define the scope of validity of `buffer`, ensuring that the underlying `MutableSpan` and the binding it depends on both remain valid through the end of the closure. They have the same shape as the equivalents on `Array` because they fulfill the same purpose, namely to keep the underlying binding alive.
535
+
These functions use a closure to define the scope of validity of `buffer`, ensuring that the underlying `MutableRawSpan` and the binding it depends on both remain valid through the end of the closure. They have the same shape as the equivalents on `Array` because they fulfill the same purpose, namely to keep the underlying binding alive.
536
536
537
537
#### <aname="extensions"></a>Properties providing `MutableSpan` or `MutableRawSpan` instances
538
538
@@ -657,7 +657,7 @@ During the evolution of Swift, we have learned that closure-based API are diffic
657
657
658
658
#### Omitting extensions to `UnsafeBufferPointer` and related types
659
659
660
-
We could omit the extensions to `UnsafeMutableBufferPointer` and related types, and rely instead of future `MutableSpan` and `MutableRawSpan` initializers. The initializers can have the advantage of being able to communicate semantics (somewhat) through their parameter labels. However, they also have a very different shape than the `storage` computed properties we are proposing for the safe types such as `Array`. We believe that the adding the same API on both safe and unsafe types is advantageous, even if the preconditions for the properties cannot be statically enforced.
660
+
We could omit the extensions to `UnsafeMutableBufferPointer` and related types, and rely instead of future `MutableSpan` and `MutableRawSpan` initializers. The initializers can have the advantage of being able to communicate semantics (somewhat) through their parameter labels. However, they also have a very different shape than the `mutableSpan` computed properties we are proposing for the safe types such as `Array`. We believe that the adding the same API on both safe and unsafe types is advantageous, even if the preconditions for the properties cannot be statically enforced.
661
661
662
662
## <aname="directions"></a>Future directions
663
663
@@ -667,7 +667,7 @@ Note: The future directions stated in [SE-0447](https://github.com/swiftlang/swi
667
667
668
668
`MutableSpan` represents a region of memory and, as such, must be initialized using an unsafe pointer. This is an unsafe operation which will typically be performed internally to a container's implementation. In order to bridge to safe code, these initializers require new annotations that indicate to the compiler how the newly-created `Span` can be used safely.
669
669
670
-
These annotations have been [pitched][PR-2305-pitch] and, after revision, are expected to be pitched again soon. `MutableSpan` initializers using lifetime annotations will be proposed alongside the annotations themselves.
670
+
These annotations have been [pitched][PR-2305] and, after revision, are expected to be pitched again soon. `MutableSpan` initializers using lifetime annotations will be proposed alongside the annotations themselves.
671
671
672
672
#### Functions providing variants of `MutableRawSpan` to `MutableSpan`
673
673
@@ -717,6 +717,6 @@ The range of `extracting()` functions proposed here expands upon the range accep
717
717
718
718
#### <aname="OutputSpan"></a>Delegated initialization with `OutputSpan<T>`
719
719
720
-
Some data structures can delegate initialization of parts of their owned memory. The standard library added the `Array` initializer `init(unsafeUninitializedCapacity:initializingWith:)` in [SE-0223][SE-0223]. This initializer relies on `UnsafeMutableBufferPointer` and correct usage of initialization primitives. We should present a simpler and safer model of initialization by leveraging non-copyability and non-escapability.
720
+
Some data structures can delegate initialization of parts of their owned memory. The standard library added the `Array` initializer `init(unsafeUninitializedCapacity:initializingWith:)` in [SE-0245][]. This initializer relies on `UnsafeMutableBufferPointer` and correct usage of initialization primitives. We should present a simpler and safer model of initialization by leveraging non-copyability and non-escapability.
721
721
722
722
We expect to propose an `OutputSpan<T>` type to represent partially-initialized memory, and to support to the initialization of memory by appending to the initialized portion of the underlying storage.
0 commit comments