SE-0456: Add Span-providing Properties to Standard Library Types

[ksluder (Kyle Sluder)]

@Karl

So what would be the difference between a MutableSpan stored in an immutable (let) binding and a regular Span?

We went through this with Atomic, and the solution was “you can’t use var”.

@Joe_Groff

Interactions with the ownership and exclusivity model

A lot of the discussion centered on the way atomics fit into the ownership model. Almost all of the Atomic type’s API is borrowing, because atomic operations are meant to be safe even when multiple operations happen simultaneously so exclusive access isn’t necessary. This has the surprising implication that an atomic’s contained value can be updated even when it appears in a let property or as part of an otherwise-immutable aggregate. For most types, the borrow model and the law of exclusivity govern whether a value is immutable or mutable, but atomics and other concurrency primitives reveal that the more fundamental property being governed is shared vs. exclusive access. Atomics don’t require exclusive access in order to be updated, and enforcing exclusivity by our usual non-thread-safe mechanism would be counterproductive and introduce unsafety, so in the vast majority of cases atomic properties ought to be declared as let properties.

Since there’ll be a natural inclination to think of atomics as being mutable and incorrectly declare them as var, the proposal includes a provision to raise a diagnostic preventing var declarations of Atomic type. There was vigorous debate over how much this expansion compromises the core promises of the language, how APIs can separate mutating and nonmutating access to their atomic state, and whether we should consider an alternative model. We could for instance say that var x: Atomic is treated as a shared-borrows-only declaration despite the var, and only allow atomic update operations on atomic fields visible as var. These alternative schemes break down in the face of abstraction and composition, though, since the special behavior of Atomic under ownership is still present when Atomic is used as a generic parameter or appears as a component of a noncopyable struct or enum. We would have to introduce new generic constraints and/or transitive type properties to mark these “atomically updatable” types separately in order to keep atomics and similar concurrent types fully separated from “normal” types. On the other hand, the “immutable vs. mutable really means shared vs. exclusive”model as proposed works within the framework we already have without surfacing a new end-user-level language concept. It also follows the footsteps of Rust, where atomics have behaved like this from before Rust 1.0, and Rust’s atomics don’t seem to have caused any catastrophic effects or lasting confusion in that community. The Language Steering Group believes that this is the right model for Swift as well, and accepts this aspect of the proposal as is.