[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Gwendal Roué]

> Le 13 sept. 2017 à 07:35, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> 
> 
> On Wed, Sep 13, 2017 at 00:26 Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> wrote:
> 
>> Le 13 sept. 2017 à 06:28, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> a écrit :
>> 
>> 
>> On Tue, Sep 12, 2017 at 23:26 Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> wrote:
>> 
>> > Le 13 sept. 2017 à 04:05, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> a écrit :
>> >
>> > On Tue, Sep 12, 2017 at 2:30 PM, Gwendal Roué <gwendal.roue at gmail.com <mailto: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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170913/c334395a/attachment-0001.html>