>> In none of those cases, the compiler emits any warning. It's thus easy to >> forget or miss the problem, and uneasy to fix it (you'll need a runtime >> failure to spot it, or a thorough code review). >> >> I hope you agree with this last sentence. This unbalance between the >> easiness of the mistake and the easiness of the fix should ring a bell to >> language designers. > > Suppose instead this were about a protocol named Fooable and a requirement > called foo() that has a default implementation. Everything you just talked > about would apply equally. Am I to understand that you are opposed to default > implementations in general? If so, then that’s got nothing to do with > synthesized Equatable conformance. If not, then you’ll have to justify why.
Sounds like a good argument, until one realises that if a protocol does not provide a default implementations for a method, it may be because a default implementations is impossible to provide (the most usual case), or because it would be unwise to do so. And indeed, the topic currently discussed is not if we should remove or not default implementations. Instead, the question is: is it wise or not to provide an *implicit* default Equatable/Hashable/XXX implementation? The tenant of explicit synthesis attempt to say that it would be unwise to do so. Please don't have us repeat again, that would be disrespectful. BTW, Happy Keynote to everybody! Gwendal _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
