<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 12, 2017 at 8:10 AM Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com">gwendal.roue@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> There is this sample code by Thorsten Seitz with a cached property which is quite simple and clear : <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html</a><br>
>><br>
>> This is the sample code that had me enter the "worried" camp.'<br>
>><br>
> I really like Thorsten's example, because it actually proves that requiring explicit derivation is NOT the correct approach here. (Let's set aside the fact that Optionals prevent synthesis because we don't have conditional conformances yet, and assume that we've gotten that feature as well for the sake of argument.)<br>
><br>
> Let's look at two scenarios:<br>
><br>
> 1) Imagine I have a value type with a number of simple Equatable properties. In a world where synthesis is explicit, I tell that value type to "derive Equatable". Everything is fine. Later, I decide to add some cache property like in Thorsten's example, and that property just happens to also be Equatable. After doing so, the correct thing to do would be to remove the "derive" part and provide my custom implementation. But if I forget to do that, the synthesized operator still exists and applies to that type. If you're arguing that "derive Equatable" is better because its explicitness prevents errors, you must also accept that there are possibly just as many cases where that explicitness does *not* prevent errors.<br>
<br>
It looks like it is true, but it is not. The implicit world is harder to deal with. And this is because in the implicit world, you never know if conformance has been synthesized or not. In the explicit world, you know: it's plain written down.<br>
<br>
To see this point, please play the game I've proposed to Xiaodi at <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039710.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039710.html</a></blockquote><div><br></div><div>Since your game involves the specific question of a property that should not be considered for Equatable synthesis, and since SE-0185 explicitly calls out the notion of transient properties as a future direction to solve that specific problem, then my solution is "I declare the property as transient."</div><div><br></div><div>Surely this is an acceptable solution? It achieves the goal you set, and more concisely/quickly than the ways you proposed in that post. It doesn't require me to go fishing through code; the act of adding the property and making it transient is completely localized to one place (it's one line!). If there's a synthesized implementation of Equatable, then the property gets ignored as desired. If there's a handwritten implementation, then the new property is already ignored because it wasn't there to begin with, but the transient declaration still provides valuable information to the reader of the code about the intention.</div><div><br></div><div>If the rebuttal to that is going to be "a developer may not know about transient", then where do we draw the line at expecting users to know how to use the features their language? It's a significant leap to go from "developers might do the wrong thing" to "so this specific approach is the only right way to fix it."</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> 2) Imagine I have a value type with 10 Equatable properties and one caching property that also happens to be Equatable. The solution being proposed here says that I'm better off with explicit synthesis because if I conform that type to Equatable without "derive", I get an error, and then I can provide my own custom implementation.<br>
<br>
Yes.<br>
<br>
> But I have to provide that custom implementation *anyway* to ignore the caching property even if we don't make synthesis explicit. Making it explicit hasn't saved me any work—it's only given me a compiler error for a problem that I already knew I needed to resolve.<br>
<br>
Oh, so compiler errors and warnings bring no information to you? :-) I'm impressed, but I'll keep on focusing on designing a language for average developpers, not only geniuses.<br>
<br>
Replay your argument and imagine that compiler outputs are useful to you. This will change your conclusion.<br>
<br>
Gwendal<br>
<br>
</blockquote></div></div>