[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Xiaodi Wu]

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

>
> 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> 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.
>
>
> 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.
>

Keep in mind that by posting to this list, you are also demanding other
people spend their free time on the issue. And again, these issues have
already been discussed. If a point is made once but doesn't carry the day,
repeating it again and again doesn't make it more convincing.


> 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/039710.html
>
> Gwendal
>

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