@swift-ci create

I disagree that protocol stubs are wrong here, in both cases. Consider

struct S<T>: Equatable {
  var id: UUID
  var t: T
}

Which is more rhetorical than it needs to be, as even the leading string member from before would do for an externally-imposed notion of identity. We could offer a conditional conformance in simple cases, but it becomes unclear in others. For example, suppose the user were to write their own (ordered) multi-map type

struct Pair<One, Two> { /* ... */ }

We can offer

extension Pair where One: Equatable { /* ... */ }
extension Pair where Two: Equatable { /* ... */ }
extension Pair where One: Equatable, Two: Equatable  { /* ... */ }

To you and I it is obvious which one of these is intended, but in the general case, the resulting decision space size is combinatorial in the number of generic parameters, no?

I understand what you're getting at, but I feel like 80%-90% of the time, what I want is the compiler to synthesize things for me. I very rarely want to write my own Equatable. Not just in Swift, even in Haskell or Rust, I almost always want the compiler to derive Eq and Ord.

That said, I don't think it's productive for us to go back and forth on this if it's a disagreement on how frequently one case happens vs the other. I can take a look at some open source code when I have some time to spare and count when one situation happens vs the other.

FWIW, I think we should offer both alternatives as fix-its and let the user choose whether he wants to make all the members Equatable or add the stub.

That's also a reasonable alternative IMO, but Xcode doesn't currently have a good way to surface things as alternatives in the fix-it UI (I think?), so it's difficult to convey that those are alternatives rather than multiple things that need to be fixed.

It does, you just need to attach multiple notes to an error/warning and each note can have its own fix-it. We already do that, e.g. when you access a member of an Optional without unwrapping it.