> Le 12 sept. 2017 à 12:01, Xiaodi Wu <[email protected]> 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.
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
