On Wed, Sep 13, 2017 at 00:26 Gwendal Roué <[email protected]> wrote:
> > Le 13 sept. 2017 à 06:28, Xiaodi Wu <[email protected]> a écrit : > > > On Tue, Sep 12, 2017 at 23:26 Gwendal Roué <[email protected]> wrote: > >> >> > 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 > > > Explicit (e.g., "AutoEquatable") and implicit synthetic behavior were both > considered during the proposal which approved the implicit behavior. This > question has been asked and answered. > > > We're in a new thread now, which may drive the core team into > reconsidering a previous decision. > > It happens. You may remember a funny debate about SE-0110. In the end a > question that had been asked and answered got a whole new answer. > > We're all here to improve the language. That's why I sometimes participate > in this mailing list. > After implementation, sometimes new insights arise from user experience that weren't originally anticipated. This can prompt reconsideration. Again, this is not the case here; decisions made are made.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
