[Returned for revision] SE-0427: Noncopyable generics

Evolution Announcements
1

The review of SE-0427: Noncopyable generics has concluded and the feedback was positive overall - reviewers acknowledged that the problem solved by SE-0427 is extremely important for Swift's ownership story, and many noted that they are excited to use the feature. The Language Steering Group has decided to accept the proposal in principle, and return for revision to address the following minor points raised during review:

  • Inference of Copyable requirements on conditional conformances to Copyable is confusing; requirements in this case should be made explicit.
  • Reviewers noted that defaulting type parameters to Copyable but not associated types further diverges the difference between primary associated types and type parameters. The Language Steering Group agrees, and believes that noncopyable associated types should be subsetted out of this proposal. Noncopyable associated types have a lot of open design questions, and should be considered in a dedicated proposal.

The following critical points were also discussed during the review.

  • 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 ~Copyable altogether. 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 Copyable requirement or unconditional conformance when there is an explicit ~Copyable suppression. 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.

Holly Borla
Review Manager

24 Likes