<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Aug 2017, at 10:32, Martin Waitz <<a href="mailto:tali@admingilde.org" class="">tali@admingilde.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Haravikk,<br class=""><br class="">Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution:<br class=""><blockquote type="cite" class="">I don't feel that conforming to<br class="">Equatable/Hashable is sufficient as an opt-in. Consider for example<br class="">someone who declares their type as Equatable/Hashable, then sets to<br class="">work on the details of their type, forgetting to implement the actual<br class="">equatable/hashable behaviour they want.<br class=""></blockquote><br class="">This is no different than a default implementation of the protocol.<br class="">In fact, the proposal just adds something like this:<br class=""><br class=""> extension Struct<A, B, ...>: Equatable where A: Equatable, B: Equatable, ... {<br class=""> static func ==(lhs: Self, rhs: Self) -> Bool { /* insert implementation here */ }<br class=""> }<br class=""><br class="">We don't require/support some special keywords for other protocols with default implementation either,<br class="">so I see no reason to add them here.<br class=""><br class="">Your concerns are orthogonal to this proposal and should be discussed independently.</div></div></blockquote><br class=""></div><div>I disagree.</div><div><br class=""></div><div>This is not the same as a default protocol implementation, as a default implementation can only act upon properties/methods that are clearly defined by the protocol itself. This feature by comparison is an automatic implementation that by design must make assumptions about the contents of a concrete type.</div><div><br class=""></div><div>Consider a type that contains some kind of "volatile" data, i.e- properties that are not necessarily crucial to the type, and so should not be considered during equality. If I make a mistake and end up using the synthesised test for equality, then two values that should be identified as equal, will not be equated as such because the synthesised option cannot account for implementation details that it has no awareness of.</div><div><br class=""></div><div>This has come up in discussion in the past, where I argued for some means of marking values to prevent them from being included in the synthesised method(s). This is covered in alternatives as "transient" values, but I disagree with the conclusion that this can simply be added later, as it is IMO crucial to the way this feature would work. Even if there were a @transient attribute or whatever from the start, I'd still prefer to set this within the context of having explicitly asked for Equatable/Hashable to be synthesised, and without such a feature it only makes it more crucial that the opt-in occur in a manner more explicit than conforming to Equatable/Hashable.</div><div><br class=""></div><div>My disagreement pretty much boils down to the fact that I do not feel that opting in simply by conforming is sufficient given that the desired behaviour is assumed; I strongly feel that a more explicit declaration of "I specifically want to use this automatic behaviour" is required, either via attribute or conforming to a more explicit protocol.</div><div><br class=""></div><div>I actually <b class="">like</b> the fact that conforming to Equatable requires me to implement ==, as it ensures that I do-so, and prefer that that behaviour remain, as it forces me to do something about it. Even with synthesised behaviour as an option, it should be exactly that, an option; i.e- when my conformance to Equatable fails, I can choose either to implement ==, or opt-in to an automatic substitute.</div></body></html>