> Le 13 sept. 2017 à 04:05, Xiaodi Wu <[email protected]> a écrit : > > On Tue, Sep 12, 2017 at 2:30 PM, Gwendal Roué <[email protected]> wrote: > >> 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? > > Right, _that_ is the question. It was asked during review for the proposal, > and the agreed upon answer is _yes_.
Wrong. This whole thread is about *explicit* synthetic behavior;. If an agreed proposal has to be invalidated in the way, _so be it_. Gwendal _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
