Hi all,
The review for SE-0426: BitwiseCopyable ran from March 6th to March 20th. The Language Steering Group has decided to return the proposal for revision.
Feedback on the proposal mostly centered around whether BitwiseCopyable met the definition of a "marker protocol" and whether it should be broken down into a more fine-grained decomposition of traits. The Language Steering Group is asking the proposal authors to revise the proposal to clarify some of these questions.
Splitting BitwiseCopyable into a composition
Some reviewers asked whether BitwiseCopyable was the right level of abstraction or whether it should be represented as a composition involving copyability, bitwise-movability, and trivial-deinitialization. The Language Steering Group believes that those more granular traits could be useful in the future but agrees that the proposal in its current form does not need to define them. If there is a need to decompose BitwiseCopyable in the future, the compiler can be updated to recognize a specific composition and treat it as equivalent to a conformance to BitwiseCopyable.
BitwiseCopyable as a marker protocol
The proposal defines BitwiseCopyable as a marker protocol. While marker protocols are an undocumented feature in Swift, the proposal that introduced them (SE-0302: Sendable and @Sendable closures) does give them an official definition. While BitwiseCopyable is defined to be similar in some ways to other marker protocols, we do not believe that it meets the full definition or shares the same needs. The restrictions imposed by marker protocols originate from the need for Sendable to be extremely low-overhead to solve practical interoperability problems with pre-concurrency libraries. This is not the case for an inherent trait like BitwiseCopyable, which can still be lightweight without imposing the same limitations.
Rather than having to contort the definition of "marker protocol" to fit this use case, the Language Steering Group asks the authors to define BitwiseCopyable as simply "a protocol" and to more explicitly describe any special restrictions imposed upon it. For example,
- Since information about bitwise-copyability is already present in type metadata, can
BitwiseCopyablehave no witness table overhead? - Should users be allowed to write
extension BitwiseCopyableor prohibited from doing so? If they are allowed to, could this lead to member namespace pollution? - Can conformance to
BitwiseCopyablebe checked dynamically (even if left as a future direction)? This one is discussed further below.
Dynamic casting
The proposal authors mention dynamically checking bitwise-copyability as a future direction via a MemoryLayout API. The Language Steering Group is fine with subsetting this out as a future direction, but we ask that the proposal authors consider a future direction where it can be queried using standard dynamic casts (is, as?) instead of a new API. Furthermore, we ask the authors to be explicit about any back-deployment limitations that would be imposed on these dynamic casts.
Supporting dynamic casts in the future should also permit BitwiseCopyable to be used as a generic constraint for a type to conditionally conform to some other non-marker protocol, which is another capability that marker protocols do not have.
Suppression of BitwiseCopyable
The Language Steering Group believes—for consistency with other suppressions recently and currently pitched—that the syntax ~BitwiseCopyable is preferred over the proposal's use of @available to suppress the inferred conformance.
We believe that it makes sense for an author to want to suppress the otherwise inferred conformance if they wish to explicitly avoid promising that a type that is BitwiseCopyable today may always remain so. In addition to this and potentially other rationales, we would like for the proposal to be more explicit about what it actually means to suppress an inferred conformance to BitwiseCopyable. In our discussion, we came to the conclusion that suppressing BitwiseCopyable would not suppress the actual physical bitwise-copyability of a type, as this is an inherent trait of the type at the time of its writing, but rather that it merely suppresses the compiler's ability to statically reason about bitwise-copyability. We further ask that the proposal elaborate on what this would mean for dynamic casts in the future—for example, would a type declared ~BitwiseCopyable still evaluate to true for is BitwiseCopyable at runtime if it is physically a bitwise-copyable type?
Once the revisions above have been made, the Language Steering Group will schedule another review of the revised proposal.
Thank you for participating in Swift Evolution!
—Tony Allevato
Review manager