<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">Can the opt-in conformance be declared in an extension? If so, can the extension be in a different module than the original declaration? If so, do you intend any restrictions, such as requiring all members of the type declared in a different module to be public? My initial thought is that this should be possible as long as all members are visible.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Declaring the conformance in an extension in the same module should definitely be allowed;</div></div></div></div></blockquote><div><br class=""></div><div>Please follow the precedent of the Codable proposal as closely as possible. If you’d like this to be successful for Swift 4, you should look to scope it as narrowly as possible. Because it is additive (with opt-in), it can always be extended in the future.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> I believe this would currently be the only way to support conditional conformances (such as the `Optional: Hashable where Wrapped: Hashable` example in the updated draft), without requiring deeper syntactic changes.</div></div></div></div></blockquote><div><br class=""></div><div>This proposal doesn’t need to cover all cases, since it is just sugaring a (very common) situation. Conditional conformances to Hashable could be written manually.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">I'm less sure about conformances being added in other modules,</div></div></div></div></blockquote><div><br class=""></div><div>It is a bad idea, it would break resilience of the extended type.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">But after writing this all out, I'm inclined to agree that I'd rather see structs/enums make it into Swift 4 even if it meant pushing classes to Swift 4+x.</div></div></div></blockquote><div><br class=""></div><div>Agreed, keep it narrow to start with.</div><br class=""></div><div>Also, I don’t know how the rest of the core team feels about this, but I suspect that they will be reticent to take an additive proposal at this late point in the schedule, unless someone is willing to step up to provide an implementation.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>