<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=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 3:29 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><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; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On 19 Aug 2017, at 19:46, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class="">Agreed. To be clear though; in spite of my pessimism this<span class="Apple-converted-space"> </span><b class="">is</b> a feature that I<span class="Apple-converted-space"> </span><b class="">do</b><span class="Apple-converted-space"> </span>want, but I would rather not have it at all than have it implemented in a way that hides bugs and sets a horrible precedent for the future.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I tried to make a split thread for this, but would you object to synthesized conformance if we had to explicitly add a command within the definition block to trigger the synthesis? If we add strong type-aliases, we could reuse the directive to copy an interface (method, inner type, property, or conformed-to protocol) from the underlying type to the current type for synthesis too. The only problem would be backward compatibility; once added, we would urge users to explicitly list “publish Equatable” for synthesis, but what about code that already uses the implicit version (since this feature will probably be released for at least one Swift version by the time strong type-aliases happen), do we force users to change their code?</div></div></div></blockquote><br class=""></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; -webkit-text-stroke-width: 0px;" class="">I would rather no code at all use the implicit version; one of my points is that it's not something that's easily changed after the fact, which is why it needs to be done correctly now.</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; -webkit-text-stroke-width: 0px;" class=""><br class=""></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; -webkit-text-stroke-width: 0px;" class="">I'm open to any method that makes opting in to the synthesised conformance explicit; I still think a specifically named protocol is the simplest, but I'm not married to that as a solution; attributes, keywords etc. are all fine too, whatever is the easiest way to opt-in to the behaviour explicitly without ambiguity. I'm not 100% sure exactly what you mean by "add a command within the definition block", or is an attribute/keyword what you meant?</div></div></blockquote><div><br class=""></div><div>The syntax to copy an interface from an underlying type to one of its strong type-aliases is a new directive within the definition block:</div><div><br class=""></div><div><font face="Monaco" class="">alter MyInt16: Int16, Hashable {</font></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Monaco" class="">publish Equatable // Automatically copies definitions from Int16 needed to conform to Equatable</font></div></div><div><div><font face="Monaco" class="">var hashValue: Int { /*…*/ } // A protocol can be completed with a mix of published and direct definitions</font></div></div></blockquote><div><div><font face="Monaco" class="">}</font></div><div><br class=""></div><div>Since we would be introducing an explicit way to declare implementation of a conformance (the “publish” directive), we could reuse the directive for Equatable/Hashable/Encodable/Decodable definitions in non-strong-aliases and make the current implicit definitions obsolete. The problem then would be backwards compatibility; could we force users to go from implicit to explicit synthesized conformance?</div><div><br class=""></div><div>The original point of publishing is to selectively control which parts of the underlying type’s interface get copied. Automatically synthesized conformance, if it stays after strong type-aliases are introduced, would screw with that (unless synthesized conformance is ignored for strong type-aliases; i.e. our conformance exception gets a counter exception).</div><div><br class=""></div><div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></div></body></html>