[swift-evolution] [Proposal] Explicit Synthetic Behaviour

Xiaodi Wu xiaodi.wu at gmail.com
Wed Sep 13 00:35:34 CDT 2017

On Wed, Sep 13, 2017 at 00:26 Gwendal Roué <gwendal.roue at gmail.com> wrote:

> Le 13 sept. 2017 à 06:28, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> On Tue, Sep 12, 2017 at 23:26 Gwendal Roué <gwendal.roue at gmail.com> wrote:
>> > Le 13 sept. 2017 à 04:05, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
>> >
>> > On Tue, Sep 12, 2017 at 2:30 PM, Gwendal Roué <gwendal.roue at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170913/2f38233a/attachment.html>

More information about the swift-evolution mailing list