[swift-evolution] [Proposal] Explicit Synthetic Behaviour

Gwendal Roué gwendal.roue at gmail.com
Tue Sep 12 23:26:06 CDT 2017


> 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



More information about the swift-evolution mailing list