SE-0267 — `where` clauses on contextually generic declarations

Evolution Proposal Reviews
2

This is an additive change with no impact on the ABI and existing code.

While this doesn’t change the ABI, I think it will open up new surface area in the ABI, because these two declarations:

struct Box {
    func sequence() -> [Box<Wrapped.Element>] where Wrapped: Sequence { ... }
}

extension Box where Wrapped: Sequence {
    func sequence() -> [Box<Wrapped.Element>] { ... }
}

Will, AFAIK, have different name manglings. In a binary framework, switching from one to the other will be an ABI-breaking change.

We’re already coping with this issue in generic declarations—if sequence() had a generic parameter, you could use a where clause in much the same way, which would introduce an ABI break just like this—so in some sense, this ship has already sailed. Still, I don’t like opening up more code to this issue.

(We can’t correct the ABI for generic types; that would be an ABI break. And yes, there is at least one public Apple API that would break.)

On the other hand, the current half-support for these kinds of generic constraints is very irregular, and even though it’s not in scope for this specific proposal, adding this might bring us closer to supporting where Element: Equatable in protocols, which I very badly want. So I’m torn by this proposal. I’m not sure what to recommend—I just know that these are aspects of it that we should think about.

3 Likes