[Accepted] SE-0427: Noncopyable generics

Evolution Announcements
1

The second review for SE-0427: Noncopyable generics has ended and the proposal has been accepted.

The second review was of an amended proposal that required explicit statement of the requirements of conditional conformances to Copyable (rather than leaving them implied via the default rule), and removed the support for associated types to be non-copyable, leaving that to a future direction.

During the review, it was noted that the subsetting out associated types left an inconsistency between the similar way that constraints work on generic parameters, which are supported. The steering group recognizes this, but felt that more time was needed for the right solution for associated types to be worked on, whilst not wanting to hold back further progress on this important feature in Swift 6.

Concern was also raised regarding the handling of future potentially suppressible constraints (such as Escapable), and whether these should also be required to be restated explicitly with every conformance, or could be inferred when conditionally conforming a type to Copyable. This aspect was not covered in the text of SE-0427 itself, since it proposed only the first generically suppressible conformance. But the steering group agreed that the current implementation on main when enabling the experimental Escapable feature was potentially inconsistent. However, this will only become an issue once Escapable (or another defaulted-but-supressible constraint) is actually introduced into the language, so discussion of that behavior can be had during the proposal review of that feature in a later Swift version.

Additional points were covered during the first review, and are restated here for reference:

  • The majority of the discussion involved reasoning about what ~Copyable means, and specifically what it means to "suppress Copyable " in the various positions a protocol conformance can appear in, including protocol refinement, a conformance clause, and a generic conformance requirement. There was discussion about using a different syntax in the difference places you can write ~Copyable , or changing the syntax of ~Copyablealtogether. The Language Steering Group believes that the ~Copyable syntax as proposed is the best choice due to the existing use from SE-0390, the need for a syntax in existential types, e.g. any P & ~Copyable, and the Language Steering Group believes that no syntax will alleviate the need for documentation or other explanation when encountering the syntax for the first time in code. There will be a learning curve for ~Copyable regardless of the choice in syntax, and the Language Steering Group accepts the proposed syntax as-is.
  • Reviewers noted that having to repeat ~Copyable may become annoying for programmers opting into non-copyable. The Language Steering Group believes the Copayble requirements are the right default, and introducing difference inference rules in extensions for different declarations would lead to confusion.
  • There was discussion about whether the compiler should prevent an explicit Copyablerequirement or unconditional conformance when there is an explicit ~Copyablesuppression. The proposal authors argued strongly in favor of the proposed behavior to emit an error to avoid confusion. The Language Steering Group agrees, and the restriction can be lifted later if practical use surfaces a need for allowing this (such as tools or macros that generate conformances to Copyable).

Thank you to everyone who participated in the pitch and proposal review; your contributions help make Swift a better language.

Ben Cohen
Review Manager

26 Likes