[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Gwendal Roué]

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

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