> Le 13 sept. 2017 à 07:35, Xiaodi Wu <xiaodi...@gmail.com> a écrit : > > > On Wed, Sep 13, 2017 at 00:26 Gwendal Roué <gwendal.r...@gmail.com > <mailto:gwendal.r...@gmail.com>> wrote: > >> Le 13 sept. 2017 à 06:28, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> a écrit : >> >> >> On Tue, Sep 12, 2017 at 23:26 Gwendal Roué <gwendal.r...@gmail.com >> <mailto:gwendal.r...@gmail.com>> wrote: >> >> > Le 13 sept. 2017 à 04:05, Xiaodi Wu <xiaodi...@gmail.com >> > <mailto:xiaodi...@gmail.com>> a écrit : >> > >> > On Tue, Sep 12, 2017 at 2:30 PM, Gwendal Roué <gwendal.r...@gmail.com >> > <mailto:gwendal.r...@gmail.com>> 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.
If I take on my free time exposing issues, it's because I hope that maybe some reader will consider them with proper attention, then maybe agree that there is an issue worth investigating, and then many conclude that a made decision has to be reverted. That's a multi-step process. And that process starts with a proper read of the issues that have been exposed. For reference, here are some issues with implicit synthesis: - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039704.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039704.html> - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039710.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039710.html> Gwendal
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
