Scoped Conformances

[dabrahams (Dave Abrahams)]

@Jumhyn

The proposal says, and I agree, that the most "natural" solution looks something like this:

extension Equatable where Self: Wrapper, Value: Comparable {
  public static func <(a: Self, b: Self) -> Bool { // error!
    a.value < b.value
  }
}

Please be careful about attributing statements, especially when you add words in quotation marks. The proposal does not, in fact, say that. The proposal implies it's the most natural solution to the problem as originally stated, but as noted later in the proposal, we have a slightly different problem to solve.

Is there a way that we could make this example meaningful, rather than add new syntax?

Perhaps we could, but it would not cover the use case of the proposal authors, in which the equivalent of X and Wrapper are both public, but the conformance of X to Wrapper should not be exposed publicly.

ETA: Ah, I see this is discussed some in the Future directions section. To me, this seems like the "simpler" version of the feature, with full-fledged scoped conformances being the extension. Is there a reason to approach them in the order this proposal suggests, rather than the other way around?

Two reasons:

1. As noted in the pitch, to enable what you're proposing as more basic, someone has to prove that it's okay for public API to be implemented by extensions that are conditional on non-public names. I don't know whether that's a problem or not, but our pitch as stated avoids that issue. If it's not a problem, so much the better; let's have that feature too!
2. More importantly, we'd have no way of eliminating binary size bloat for users of Structural.