<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 11:18 AM Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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"><br><div><blockquote type="cite"><div>On 7 Sep 2017, at 18:53, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-252206569380553808Apple-interchange-newline"><div><div dir="ltr" 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><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 10:39 AM Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>> wrote:<br></div><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"><div>Le 7 sept. 2017 à 14:45, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>> a écrit :</div><br class="m_-252206569380553808m_9067213542021244859Apple-interchange-newline"><div><span 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;float:none;display:inline!important">Right, let's make sure we're talking about the right thing here. Gwendal, your issue isn't with synthesis in the form of Codable or the new additions to Equatable/Hashable which are opt-in-by-conformance, it's with the specific case of raw value enums or enums without associated values where the synthesis is implicit with no way to opt-out. That's a big difference.</span><br 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></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Yes.</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><span 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;float:none;display:inline!important">I can definitely see the latter being an issue if it were more widespread, and I'd be supportive of those enums being required to declare their conformance for consistency (though it would be source breaking).</span><br 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></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Yes, unfortunately.</div></div><div style="word-wrap:break-word"><div><br><br><blockquote type="cite"><div><span 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;float:none;display:inline!important">However, I still haven't seen a real issue that has come up because of the distinction being drawn here between default implementations vs. implementations that can access other parts of the concrete type. It sounds like this discussion is trying to protect against a hypothetical problem that hasn't happened yet and may not happen; it would be helpful to show some motivating real-world cases where this is indeed a severe problem.</span></div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>Yes. I'm not talking about implementation itself. I know this has been the main topic until I have tried to bring in the topic of the consequences of non-avoidable synthesis (extra methods that may conflict with userland methods).</div><div><br></div><div>If you ask me for a real-world case, then I think I gave one. Let me rephrase it:</div><div><br></div><div>it's impossible to define a value-backed enum without getting free Equatable conformance. This free conformance is sometimes unwanted, and I gave the example of DSLs. Now this problem is not *severe*. It's more a blind spot in the language, and finally just an unwanted side-effect of a compiler convenience,</div></div></blockquote><div><br></div><div>Again, this is not the issue that Haravikk is describing in this thread.</div><div><br></div><div>I'll clarify—your issue is specifically with the fact that enums with raw values and enums without associated values receive Equatable even without explicitly conforming to it, and therefore users have no way of opting out of it. This predates SE-0185, and I didn't propose making any changes to the conformance of those enums for source compatibility reasons, though I wouldn't be opposed to it because it makes them consistent across the board.</div><div><br></div><div>Haravikk's argument is about synthesized conformances like Codable and Equatable/Hashable in SE-0185, where the user must explicitly conform the type to those protocols. His claim is that that act of opting in is not sufficient and that it is still dangerous if those synthesized conformances can access members that are not also declared in the protocol. That's a completely separate issue to yours, and one that I hope he'll present more evidence of. Right now, requiring that you not only explicitly conform to the protocol but also explicitly request the synthesis feels like a solution without an actual problem, and is a situation we already have today with default method implementations.</div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>The simplest real-world case is easy:</div><div><br></div><div><font face="Monaco"><span class="m_-252206569380553808Apple-tab-span" style="white-space:pre-wrap"> </span>struct Foo { var data:String }</font></div><div><font face="Monaco"><span class="m_-252206569380553808Apple-tab-span" style="white-space:pre-wrap"> </span>extension Foo : Equatable {} // This currently produces an error, in future it will not</font></div><div><br></div></div></blockquote><div><br></div><div>Why is this a problem? It's no different than if someone extended Foo to conform to a protocol with a default implementation that was written in code.</div><div><br></div><div> </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>I argued this point on the specific topic for Equatable/Hashable, but it was, both during and after review, essentially ignored and the decision to synthesise implicitly never sufficiently justified. The closest that I got was "but Codable does it" which is about as weak a justification as you could possibly get as I don't really agree with it in the case of Codable either. In the case of Equatable/Hashable specifically this is arguably a breaking change that has IMO been totally ignored by the core team who haven't given any reasonable response.</div></div></blockquote><div><br></div><div>That's not a fair characterization. Just because your concerns were disagreed with does not mean they were ignored; my understanding is that the core team views these synthesized conformances as a different kind of default method (and one which could be hoisted out of the compiler once sufficient metaprogramming facilities are available).</div><div><br></div><div>The way to handle synthesized conformances was discussed during the review period for Codable, during the earlier pitch a few months ago for what became SE-0185, and again during its formal review. It's not accurate to reduce the argument you disagree with to "but Codable does it" when what you're referring to is established precedent based on those prior discussions.</div><div><br></div><div> </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>In the broader case however I still feel that synthesised behaviour should require explicit rather than implicit opt-in, as it allows us to distinguish between a developer who wants to implement requirements themselves, versus one who is happy to have one derived from their concrete type automatically. The current setup does not allow this at all.<br></div></div></blockquote><div><br></div><div>I feel like we keep going back to this, but this statement applies equally to non-synthesized default implementations. Are you suggesting that users should have to opt-in specifically to all default implementations provided by a protocol in some way beyond merely conforming to that protocol? If not, what specifically makes synthesized conformances a special case?</div><div><br></div><div> </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>In future if the role keywords are adopted we will always be able to distinguish one who wants to explicitly implicit more than just the minimum requirements.</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<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>