<div><br><div class="gmail_quote"><div dir="auto">On Wed, Sep 13, 2017 at 09:13 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 13 Sep 2017, at 03:26, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-8645001042325820365Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 12, 2017 at 11:43 AM, Haravikk via swift-evolution<span class="m_-8645001042325820365Apple-converted-space"> </span><span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span class="m_-8645001042325820365Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On 12 Sep 2017, at 12:08, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-8645001042325820365m_475396689185125937Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto"></div></div></div></div></div></blockquote></span><blockquote type="cite"><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><span><div dir="auto">On Mon, Sep 11, 2017 at 06:03 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>See, this is another flawed assumption; you are assuming that omitting a custom implementation of == is always intentional rather than an oversight, which is not guaranteed. This is one of my gripes with the retroactive change to Equatable, as it is currently<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span><b>impossible</b> to omit an implementation.</div></div></div></blockquote></span></div></div></div></div></blockquote></blockquote><span><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">Again, this applies equally to the addition of _any_ default implementation. And again, such changes don’t even require Swift Evolution approval.</div></div></div></div></div></blockquote><div><br></div></span><div>So what? Because the Swift Evolution process is currently deficient we should just give up on discussing problems with features and the language altogether?</div></div></div></blockquote><div><br></div><div>I don&#39;t claim that it&#39;s a deficiency; I claim it&#39;s reflective of Swift&#39;s opinionated take on default implementations. Are you, after all, saying that you have a problem with the addition of _any_ default implementation to an existing protocol? If so, this conversation isn&#39;t about synthesis/reflection at all.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>No, and you should know that by now. I suggest actually reading some of what I have written as I am sick of repeating myself.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><blockquote type="cite">And precisely what kind of &quot;evidence&quot; am I expected to give? This is a set of features that<span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-converted-space"> </span><b>do not exist yet</b>, I am trying to argue in favour of an explicit end-developer centric opt-in rather than an implicit protocol designer centric one. Yet no-one seems interested in the merits of allowing developers to choose what they want, rather than having implicit behaviours appear potentially unexpectedly.<br></blockquote></blockquote><blockquote type="cite"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Both options were examined for Codable and for Equatable/Hashable. The community and core team decided to prefer the current design. At this point, new insights that arise which could not be anticipated at the time of review could prompt revision. However, so far, you have presented arguments already considered during review.</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>And so far all I have heard about this is how it was &quot;decided&quot;; no-one seems interested in showing how any of these concerns were addressed (if at all), so as far as I can tell they were not, or they were wilfully ignored.</div></div></div></blockquote></div></div></div></blockquote></blockquote><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">They were addressed by being considered.</div></div></div></div></blockquote><div><br></div></span><div>And yet no-one can apparently summarise what those &quot;considerations&quot; might be, suggesting that they were either <b>not</b> considered at all, or that the &quot;consideration&quot; was so weak that no-one is willing to step forward to defend it. Either way it is not sufficient by any reasonable measure.</div><div><br></div><div>If I were to run over your foot in my car, would you be happy to accept that I &quot;considered&quot; it first?</div></div></div></blockquote><div><br></div><div>How do you mean? People wrote in with their opinions. Then, taking into account the community&#39;s response, the proposal was approved.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I mean because not once have you summarised what these alleged &quot;considerations&quot; were; if they exist then you should be able do so, yet all I am hearing is &quot;it was considered&quot;, which frankly is not an argument at all as it is entirely without substance.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto"></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Of course it is not an argument at all. It is a factual statement. The objections which you mentioned were also mentioned prior to a decision about SE-0185. The community and the core team had an opportunity to view those objections. After that time, a decision was made, having considered all the stated pros and cons which included the ones that you are now repeating. What &quot;considerations&quot; are you looking for?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto">If it was genuinely considered then someone should be able to say what points were considered and what conclusions were reached and why. And even if there <b>was</b> an earlier decision, that doesn&#39;t necessarily make it right.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">No, but it does mean that discussion of this topic has concluded on Swift Evolution.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto">We are discussing it now, and it is clear that any decision that has been made has been made poorly at best.<br></div><div dir="auto"><br></div><div dir="auto">And if you&#39;re talking about the discussion on Equatable/Hashable specifically, I&#39;m afraid your memory of the &quot;considerations&quot; is radically different to mine; as the concerns I raised were essentially ignored, as not a single person gave a justification more substantial than &quot;but, but Codable!&quot; which frankly isn&#39;t a justification at all.</div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Therefore, your argument reduces to one about which default implementations generally ought or ought not to be provided--that is, that they ought to be provided only when their correctness can be guaranteed for all (rather than almost all) possible conforming types. To which point I sketched a rebuttal above.</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>If a protocol defines something, and creates a default implementation based only upon those definitions then it must by its very nature be correct. A concrete type may later decided to go further, but that is a feature of the concrete type, not a failure of the protocol itself which can function correctly within the context it created. You want to talk evidence, yet there has been no example given that proves otherwise; thus far only Itai has attempted to do so, but I have already pointed out the flaws with that example.</div><div><br></div><div>The simple fact is that a default implementation may either be flawed or not within the context of the protocol itself; but a reflective or synthetic implementation by its very nature goes beyond what the protocol defines and so is automatically flawed because as it does not rely on the end-developer to confirm correctness, not when provided implicitly at least.</div></div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Again, if it applies generally, it must apply specifically. What is &quot;automatically flawed&quot; about the very reasonable synthesized default implementation of ==?</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>It makes the assumption that every equatable property of a type is necessarily relevant to its equality.</div></div></div></blockquote></div></div></div></blockquote></blockquote><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">No necessarily, only provisionally and rebuttably. If it’s not the case, override the default.</div></div></div></div></blockquote><div><br></div></span><div>So… entirely unlike standard default implementations which<span class="m_-8645001042325820365Apple-converted-space"> </span><b>cannot</b> &quot;provisionally&quot; assume something is relevant at all,</div></div></div></blockquote><div><br></div><div>Why not?</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Because they can only act upon properties/methods that they themselves (or a parent protocol) define. FFS, what is so unclear about that? Or are you arguing on this subject without every having actually used a protocol before?</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">There is no guarantee whatsoever that any particular default implementation is suitable for your particular conforming type. If it were so guaranteed, it would not need to be a dynamically dispatched default; it could just be a protocol extension member. Every default implementation is provisional in some way or other.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>thereby making them entirely different from synthesised/reflective implementations!</div><div><br></div><div>I&#39;m sorry, but you keep trying to argue that they&#39;re the same, but then admitting that they&#39;re not. You can&#39;t have it both ways.</div></div></div></blockquote><div><br></div><div>Well, certainly, synthesized default implementations differ from non-synthesized ones in key respects. However, they do not differ in terms of the user experience of conforming to the protocol and having to override the default.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Except that that&#39;s not true at all, is it?</div><div><br></div><div>Synthesised default implementations go much further in how they attempt (and potentially fail) to implement those defaults, and in the specific case of Equatable/Hashable they are fully implementing a protocol without a single property of method being raised as a requirement; they are utterly different at a fundamental level, no amount of mental contortion changes that fact.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">You keep repeating this; but repeated assertion doesn&#39;t make it true. The author of a type who conforms it to a protocol has to determine whether the default implementations make sense for that type. They either do or they do not; both are possible, and if they are not suitable, it does not matter one bit whether this is because it &quot;goes too far&quot; or &quot;not far enough.&quot;</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Consider for example if a type stores a collection index for performance reasons; this isn&#39;t an intrinsic part of the type, nor relevant to testing equality, yet this default implementation will treat it as such because it<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span><b>knows nothing about the concrete type&#39;s properties</b>. If a protocol does not define a property then any action taken upon such a property is necessarily based upon an assumption; just because it might be fine some of the time, does not make it any less flawed.</div><div><br></div><div>The big difference here between explicit and implicit synthetic implementations is where this assumption originates; if a method is synthesised implicitly then the assumption is made by the protocol designer alone, with no real involvement by the end developer. If I explicitly opt-in to that default however I am signalling to the protocol that it is okay to proceed. In the former case the assumption is unreasonable, in the latter it is explicitly authorised. It is a difference between &quot;I want to make the decision on what&#39;s correct&quot; and &quot;I am happy for you (the protocol designer) to decide&quot;.</div><div><br></div><div>Right now, when I conform to Equatable, it is a declaration of &quot;I will implement this&quot;, but with this retroactive implicit change it is now a declaration of &quot;implement this for me&quot;, these are two entirely different things. Consider; what if I&#39;m working on a piece of code that requires types to be Equatable, but one of the types I&#39;m using currently isn&#39;t, so I quickly throw Equatable conformance onto it and go back to what I was doing, with the intention of completing conformance later. With this change that type may now receive a default implementation that is wrong, and I&#39;ve lost the safety net that currently exists.</div></div></div></blockquote></div></div></div></blockquote></blockquote><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">Right now, it still wouldn’t compile, so I don’t see why you would do that. In the future, if you want to make it not compile, there is nothing stopping you from conforming to a non-existent “NotYetEquatable”. This was something that you asked about earlier and it was answered.</div></div></div></div></blockquote><div><br></div></span><div>So your solution is to intentionally write invalid code to work around the fact that a feature is being implemented badly?</div></div></div></blockquote><div><br></div><div>You stated a use case where you *want* the compiler to stop your code from compiling by stating a conformance to Equatable without implementing its requirements. You then stated that the major problem you have with synthesized `==` is that the compiler will now use a default implementation that you might forget about instead of stopping compilation. Therefore, I demonstrated how you could continue to have the compiler stop your code from compiling. It&#39;s not my solution that is intentionally writing invalid code; your stated aim was to be able to do so.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>My stated aim was nothing of the sort.</div><div><br></div><div>I was pointing out that right now conforming to Equatable means something entirely different from what it will mean in future if this idiotic change makes it into release. Please actually read what I write before deciding for yourself what my &#39;stated aim&#39; is.</div><div><br></div><div>I am <b>not</b> asking for workarounds to circumvent a ridiculously flawed change to the language, I am arguing why it is flawed and must be changed. If I wanted a workaround I&#39;d do what I&#39;m now seriously considering, which is ditching Swift completely, as I will not use a language if I can no longer trust the team developing it or the decisions that they make.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">You are certainly free to choose to write in any language you please; but it is certainly not appropriate to attack proposals with words such as &#39;idiot.&#39; The core team reviewed the changes in light of all comments and came to this decision. If you want to persuade them otherwise, you&#39;ll need to do more than to repeat the same comments you&#39;ve already made.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>A non-synthesised/reflective implementation cannot strictly be incorrect, because as long as it is implemented properly it will always be correct within the context of the protocol itself. It may not go quite as far as an end developer might want, but that is because they want to add something onto the protocol, not because the protocol is wrong.</div><div><br></div><div>A synthesised/reflective implementation differs because if it goes too far it is wrong not only within the context of the concrete type, but also the protocol itself, it is simply incorrect.</div></div></div></blockquote></div></div></div></blockquote></blockquote><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">Again, this is an assertion that misses the mark. If the default implementation is unsuitable for a type, it’s unsuitable whether it “doesn’t go quite as far” or “goes too far.”</div></div></div></div></blockquote><div><br></div></span><div>Because not going quite far enough is not a failure of the protocol, as protocols by their very nature can only go as far as what they define. If a protocol Foo defines two properties, a method which uses those two properties correctly, then the method is correct. A developer of a concrete type might want to add more information or tailor the behaviour, but that doesn&#39;t make the default implementation incorrect, it&#39;s just considering the type only within the context of being an instance of Foo.</div><div><br></div><div>Going too far is the opposite; it&#39;s the protocol designer messing around with stuff they do not define at all. It&#39;s only ever right by chance, as it&#39;s operating within the context of the concrete type, about which the protocol does not know anything with certainty.</div></div></div></blockquote><div><br></div><div>Yes, you have defined &quot;not going far enough&quot; and &quot;going too far&quot; based on whether an implementation uses only protocol requirements or not. However, you haven&#39;t at all demonstrated why this distinction is at all meaningful in terms of the issue you describe with a user conforming to a protocol. If there is a default implementation, either it returns the expected result for the conforming type or it does not--those are the only two choices. Are you arguing that, empirically, the default implementation for Equatable will more often be unsuitable for conforming types? If so, what&#39;s your evidence?</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>What&#39;s yours? If this issue was as &quot;considered&quot; as you constantly claim then where is the evidence that there is no meaningful distinction? Surely such evidence exists, or else the issue hasn&#39;t been considered at all, has it?</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Firstly, it is by definition not possible to prove a negative; secondly, as you are the one who created this distinction, the onus is certainly on you to provide convincing evidence of it, which you have not yet done.<br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Frankly I am sick of being asked to provide evidence when you are seemingly unwilling to do anything in return, especially when you have conveniently ignored every single example that I have already given.</div><div><br></div><div>It cuts both ways; you claim that &quot;going too far&quot; and &quot;not going far enough&quot; are the same thing? Well prove it.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">You state but do not give any rationale for the claim that the former is not wrong in some context while the latter is always wrong.</div><div dir="auto"><br></div><div dir="auto">By this line of argumentation, you’d be perfectly content if instead we simply had the default implementation of == as “return true” because it would be somehow not wrong.</div></div></div></div></blockquote><div><br></div></span><div>Only if return true were a reasonable default to give in the context of the protocol, which it clearly is not, as it&#39;s not performing any kind of comparison of equality.</div></div></div></blockquote><div><br></div><div>Sure it is; `return true` satisfies all the semantic requirements for equality: reflexivity, symmetry, transitivity; and, in the context of the protocol which only provides for this one facility (determination of equality or inequality), any two instances that compare equal _are_ completely interchangeable &quot;within the context of the protocol itself,&quot; as you would say.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>The purpose of Equatable is to identify types that can be compared for equality; returning true does not satisfy that aim because no such comparison is occurring, so your example is intentionally ridiculous.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Of course it is intentionally ridiculous. It is intended to show that _your_ claim that &quot;not going far enough&quot; is still &quot;correct within the context of the protocol itself&quot; and therefore OK for a default implementation can produce absurd results, and that these results (though they fill your criteria for &quot;correctness&quot;) are far poorer defaults than synthesized `==`, therefore demonstrating that &quot;not going far enough&quot; is certainly not somehow necessarily less &quot;wrong&quot; than &quot;going too far.&quot;</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Even a less contrived example such as comparing memory addresses doesn&#39;t fulfil the purpose of Equatable, which is all about comparing equality of different instances that might still be the same.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Put another way, what the proposal about synthesizing implementations for Equatable and Hashable was about can be thought of in two parts: (a) should there be default implementations; and (b) given that it is impossible to write these in Swift, should we use magic? Now, as I said above, adding default implementations isn&#39;t (afaik) even considered an API change that requires review on this list. Really, what people were debating was (b), whether it is worth it to implement compiler-supported magic to make these possible. Your disagreement has to do with (a) and not (b).</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Wrong. The use of magic in this case produces something else entirely; that&#39;s the whole point. It is<span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-converted-space"> </span><b>not the same</b>, otherwise it wouldn&#39;t be needed at all. It doesn&#39;t matter if it&#39;s compiler magic, some external script or a native macro, ultimately they are all doing something with a concrete type that is currently not possible.</div><div><br></div><div>And once again;<span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-converted-space"> </span><b>I am not arguing against a default implementation that cuts boilerplate</b>, I am arguing against it being implicit. What I want is to be the one asking for it, because it is not reasonable to assume that just throwing it in there is always going to be fine, because it quite simply is not.</div></div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">If you have to ask for it, then it&#39;s not a default. You *are* against a default implementation.</div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>A default implementation is an implementation that I, as the concrete type developer, do not have to provide myself. If you want default to mean only &quot;automatic&quot; then your attempt to pigeon-hole what I am arguing is incorrect, because what I am arguing is then neither about default implementations nor the means of actually implementing it, but something else entirely.</div><div><br></div><div>But as far as I&#39;m concerned it still absolutely still a default implementation whether it is requested or not; the difference is I, as the end developer, am able to refine what type of defaults that I want.</div></div></blockquote><div dir="auto"><br></div></div></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><div dir="auto">The word “default” indicates something that arises in the absence of a user indication otherwise.</div></div></div></div></blockquote><div><br></div></span><div>Then this proposal is just for a different mechanism for &quot;indicating otherwise&quot;.</div><div><br></div><div>You keep trying to argue that a synthesised/reflective default implementation is the same as a normal default implementation, yet you seem to be consistently forgetting that even if that is true without this proposal, that the very proposal itself is to change that, effectively causing a category of default implementation to become explicitly opted-into, rather than implicitly. They&#39;re still implementations that will be provided automatically, just only when they are permitted to do-so.</div></div></div></blockquote><div><br></div><div>So to be clear, you are *against* them being the *default*: you wish them to be the *otherwise*.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>You seem to be insisting upon a narrow definition of default; what I want is control over which types of default implementations are provided. Just because they must be opted-into explicitly does not stop them being &quot;default&quot;,</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Yes, they do stop being &quot;default&quot;; that is what the word means.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>as they are still implementations that I myself do not need to implement.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">There must be adjectives to describe this, but &quot;default&quot; is not it. Bottom line is: you don&#39;t agree with SE-0185 providing a synthesized default implementation for Equatable and Hashable requirements.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>The difference is that I want to actually <b>want</b> them rather than have provided through potentially flimsy assumptions made by a protocol designer. Just because there&#39;s an extra step doesn&#39;t make them any less automatic, otherwise having to conform to a protocol in the first place would also prevent them from being defaults.</div><div><br></div><div>Asking <b>for</b> something is more like a middle-ground between the two; the synthetic implementations are still possible defaults, they just aren&#39;t provided unless you allow them, while omitting the necessary keyword/attribute prevents them being used.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite">On 9 Sep 2017, at 23:17, Gwendal Roué &lt;<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>&gt; wrote:</blockquote></div><div><blockquote type="cite"><br class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-interchange-newline"><div><div style="word-wrap:break-word">All right, I&#39;ll be more positive: our science, IT, is a *constructive* science, by *essence*. If there is a problem, there must be a way to show it.<div>It you can&#39;t, then there is no problem.</div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>You mean just as I have asked for examples that prove non-synthetic/reflective default implementations are as dangerous as synthetic/reflective ones? Plenty have suggested this is the case yet no reasonable examples of that have been given either.</div><div><br></div><div>However, examples highlighting problems with the synthesised behaviour are simple:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">struct</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>Foo :<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Equatable</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>{<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>data:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">String</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>}<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures">// Currently an error, won&#39;t be in future</span></div></div></blockquote><div><br></div><div>Or something a bit more substantial:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">struct</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>KeyPair :<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Equatable</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>{</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">static</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>count:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>=<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">0</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;min-height:16px"><br></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>count:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;color:rgb(0,132,0)"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">let</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>key:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">String</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures">// This is the only property that should be equatable</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>value:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">String</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;min-height:16px"><br></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">init</span><span style="font-variant-ligatures:no-common-ligatures">(key:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">String</span><span style="font-variant-ligatures:no-common-ligatures">, value:</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">String</span><span style="font-variant-ligatures:no-common-ligatures">) {</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">                </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">let</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>count =<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">KeyPair</span><span style="font-variant-ligatures:no-common-ligatures">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">count</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>&amp;+<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">1</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">                </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">KeyPair</span><span style="font-variant-ligatures:no-common-ligatures">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">count</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>= count;<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">self</span><span style="font-variant-ligatures:no-common-ligatures">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">count</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>= count</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">                </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">self</span><span style="font-variant-ligatures:no-common-ligatures">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">key</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>= key;<span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(187,44,162)">self</span><span style="font-variant-ligatures:no-common-ligatures">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">value</span><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937Apple-converted-space"> </span>= value</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span class="m_-8645001042325820365m_475396689185125937m_3633143033702585265m_-1042113312397403379Apple-tab-span" style="white-space:pre-wrap">        </span>}</span></div></div><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">}</span></div><div><br></div></div></blockquote>Here the only important property in the key pair is the key, the value isn&#39;t important (only the keys are to be considered unique) and the count is just a throwaway value. The synthesised default implementation for this concrete type will therefore be completely wrong, likewise for Hashable, which will likely produce radically different results for instances that should be the same.</div></blockquote></div></div></div></blockquote><br></span></div><div>I notice that despite asking endlessly for examples, the ones I&#39;ve given are being ignored. In future I shall remind people asking for examples where they can shove them.</div></div></blockquote></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>And once again, totally ignored. You seem to love asking for &quot;evidence&quot; but why exactly should I bother giving anything if you ignore it when I try to?</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>