We've spent a fair amount of time discussing these "ergonomics" issues internally, and never really came up with a completely satisfactory solution for eliminating this ~Copyable spam, which I agree might be slightly repetitive in practice. The proposal as written spells out the minimum model, in a sense, because it's what has to work for the feature to make sense at all, but there are certainly additional tweaks we could make. They are pretty straightforward to implement, and mostly independent of each other, I think. I'm not sure I love any of them, but I could certainly live with them:
- We could say that an extension of an unconditionally noncopyable struct or enum does not introduce any default conformance requirements. Here there are no source compatibility concerns:
struct Holder<T: ~Copyable>: ~Copyable { var t: T }
extension Holder /* no requirements */ {} // probably what you want?
I should also mention that @xwu's proposed rule is solving a similar problem.
2. For protocols, I admit that one might intuitively think that something like defines a noncopyable T:
protocol Manager: ~Copyable { associatedtype Resource: ~Copyable }
func f<T: Manager >(_: T) /* today: where T: Copyable */ {}
This isn't source-compatible if a protocol retroactively adopts Copyable, but we could invent some way to distinguish protocols that were "born copyable", eg what a few folks are calling @retroactive ~Copyable, or as I'm going to spell it here, ?Copyable because I'm lazy:
protocol Equatable: ?Copyable {...} // strawman syntax!
protocol Manager: ~Copyable {...}
Then we could say if a generic parameter is subject to a conformance requirement to a ~Copyable protocol, we suppress the default conformance, whereas ?Copyable protocols would behave like they do today. This would be purely "syntactic" still, so eg
func f<T, U>(...) where T == U.A, U.A: Manager, U: ... /* T: Copyable still inferred here unless suppressed */
func f<T, U>(...) where T: Manager, U: ... /* T would be ~Copyable */
Similarly, protocol extensions could easily look at ?Copyable vs ~Copyable when desugaring the where clause:
extension Equatable /* where Self: Copyable */ {}
extension Manager /* no requirements */ {}
We could bring back the synthesis of the conditional conformance, but make it explicit. This was the old behavior implemented until a week ago or so:
struct G<T: ~Copyable> {} // synthesizes conditional conformance
struct G<T: ~Copyable>: Copyable {} // unconditionally copyable
struct G<T: ~Copyable>: ~Copyable {} // unconditionally noncopyable
(Now of course the first two are both unconditional Copyable.) We could of course do something like this instead:
struct G<T: ~Copyable>: ?Copyable {} // new way to request conditionally Copyable
extension G /* where T: Copyable */ {}
struct G2<T /* : Copyable */>: ?Copyable {} // probably a warning/error?
We could also say that in a conditional conformance to Copyable specifically, the where clause desugaring rules are not applied, so you'd always write out the "positive" requirements:
struct G<T: ~Copyable, U: ~Copyable>: ~Copyable {}
extension G: Copyable where T: Copyable, U: Copyable {}
extension G /* where T: Copyable, U: Copyable */ {}
This might be confusing if your conformance is only conditional on a subset of the generic parameters:
struct G<T: ~Copyable, U: ~Copyable>: ~Copyable {}
extension G: Copyable where T: Copyable {}
extension G /* where T: Copyable, U: Copyable */ {} // what?
Yes:
protocol P: ~Copyable {}
typealias PP = P & ~Copyable
func f<T: PP>(_: T) {}