[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Xiaodi Wu]

On Tue, Sep 12, 2017 at 09:53 Gwendal Roué <gwendal.roue at gmail.com> wrote:

>
> > Le 12 sept. 2017 à 12:01, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> >
> >> There is this sample code by Thorsten Seitz with a cached property
> which is quite simple and clear :
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html
> >>
> >> This is the sample code that had me enter the "worried" camp.
> >
> > Sorry, I fail to see what the problem is in that example. A method was
> invoked that changed a stored property of one instance. Therefore, it’s no
> longer equal to the other instance. If you want a custom notion of
> equality, you should implement it yourself. In the absence of such, the
> _default_ notion of equality is pretty clear.
>
> Yes, I agree with you. As long as you reason in this way, there is no
> problem at all, just a programmer error.
>
> I'll try to show that you need to play some moves further before problems
> appear. Don't look at the code as a static thing, but as a living thing.
>
> Please follow me: will you play a little programmer game? Here is a
> snippet of code. It is embedded in this Xcode project which, as you can
> see, contains hundreds of files. Your mission is to add an extra property
> which should not be considered for Equatable adoption. How do you do that?
>
>         struct S : Equatable {
>                 var x: Int
>         }
>
> The answer is:
>
> 1. Find if there is an extension somewhere that implements Equatable
> conformance.
> 2. If you are eventually sure that there is no explicit conformance yet,
> write the correct one.
>
> You may know that proving that something does not exist is harder than the
> opposite, and the step 1 above seems dubious to you. You are right. You
> thus use this smarter technique:
>
> 1. Write a dummy explicit conformance to Equatable, compile.
> 2. If compiler does not complain about duplicate implementation, conclude
> that there is no explicit conformance yet, and write the correct one.
>
> Problem solved. And nice display of smartness and funny little compiler
> tricks. </irony>
>
> ----
>
> No. Please look at the topic from above, and look at how developers are
> working. Troubles in synthesized conformance can happen for several reasons:
>
> 1. Lack of knowledge. As you tend to day, nobody is supposed to ignore the
> law, and the bug is the fault of the programmer.
> 2. The developper creates the type, plans to add specific implementation,
> and forgets.
> 3. The developper eventually adds a property and misses the fact that a
> synthesized conformance exists (and is now incorrect).
> 4. The developper eventually adds a property and misses the fact that the
> synthesized conformance is now incorrect.
> 5. The developper eventually adds a property, plans to fix the synthesized
> conformance, and forgets.
>
> Cases 2, 3 and 5 are examples of good faith mistakes.
>
> 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.


Beyond that, it's very hard to improve one's skills in face of those
> programmer errors. They have not much value beyond blind punishment. You
> can't learn from them. I'm the last one who wishes to see a weird cultural
> paranoia against Equatable: look at how "smart" and versed in Swift
> subtleties you need to be to just add a simple property to an innocuous
> struct!
>
> Gwendal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170912/337f602e/attachment.html>