Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I find the "default constraint sets" alternative particularly compelling because of future evolution. It would mean there wouldn't have to be an entirely new Collection hierarchy for noncopyable types. It would also mean that, after a new Collection hierarchy is introduced, adding a new suppressible protocol like ~Runcible wouldn't necessitate a third Collection hierarchy.
The proposal states about the "protocol-defined default requirements" alternative:
This might also serve as a way for a protocol to opt generic parameters out of defaulting to Copyable and/or Escapable when the protocol is used as a constraint, which may be desirable for protocols that are only used with noncopyable or nonescapable conformers in practice.
Even if "protocol-defined default requirements" are not adopted, I think that specific functionality would be especially helpful if an ExclusiveCopyable protocol that sits between Copyable and ~Copyable is ever introduced. Then it would be possible to make T: ExclusiveCopyable sufficient instead of making people write T: ExclusiveCopyable & ~Copyable & ~Escapable.
I am in strong favour of allowing suppressed conformances on associated types.
On the other hand, changing an associated type declaration in an library to suppress conformance is can be an ABI-breaking change. For example, an extension of a protocol providing a default implementation could have its symbol name change, as these two implementations of greet must have distinct names:
Can this clause be clarified? Under what conditions is it safe to change an existing associated type declaration (and conversely, what would make them unsafe?) What steps would need to be taken to ensure a safe transition? I ask because there are a couple of protocols in Swift Testing that would benefit from a change here.
I think this should always be an error. Because Iter is not a primary associated type of Iterable, some Iterable<Int> should be desugared only into T where T: Iterable, T. Element == Int /*, T.Iter: ~Copyable */. Given the above constraints, it does not matter if its default Iter implementation is Copyable or not.