<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 class=""><br class=""></div><div class="">The initial three cases I’d considered were:</div><div class=""><br class=""></div><div class="">1) Textual replacement inside struct/enum/class. This avoids longer boilerplate repetition, making code easier to read and refactor.</div><div class=""><br class=""></div><div class="">2) Default method arguments, like #file and #line, evaluated at the call site, not implementation site. So:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>--- A.swift ---</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class A {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>static func register(_ cls: A.Type = #Self.self)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>--- B.swift ---</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class B : A {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>static func foo() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                        </span>register()</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space:pre">        </span>In this case, the `cls` argument would resolve to B.self (with the ‘.self’ bits possibly not being needed in Swift 3).<div class=""><br class=""></div><div class="">3) Adoption points in protocols.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>protocol P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>static func implementingClass() -> P.Type {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                        </span>return #Self.self</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class A : P {}</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class B : A {}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>A.implementingClass() and B.implementingClass() would both return A.self</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I suspect that case 1 is the easiest to discuss, but all three make sense to me personally. Perhaps they should be separate proposals, perhaps not. Also, I’m not sure if the implementation would have any ABI/resilience concerns (particularly for #2 and #3 where when crossing module boundaries.</div><div class=""><br class=""></div><div class="">-tim</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 10, 2016, at 7:50 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..</div><div class=""><br class=""></div><div class="">Quick rundown:</div><div class=""><br class=""></div><div class="">struct A {</div><div class=""> ...#Self... // #Self is substituted by A</div><div class="">}</div><div class=""><br class=""></div><div class="">class B {</div><div class=""> ...#Self... // Self is substituted by B</div><div class="">}</div><div class=""><br class=""></div><div class="">class C {</div><div class=""> ... #Self... // Self is substituted by C, which is the defining type at compile time</div><div class="">}</div><div class=""><br class=""></div><div class="">I'm stepping away from endorsing or pushing this forward. If you want to pick this up and run with it, it's yours.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 10, 2016, at 8:34 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Can you clarify where would #Self would be allowed?</div><div class=""><br class=""></div><div class="">* property declarations</div><div class="">* method signatures</div><div class="">* method and computed property bodies</div><div class="">* all of the above</div><div class=""><br class=""></div><div class="">I would like to see this and allowed in all of the above.</div><div class=""><br class=""></div><div class="">We should also consider allowing this in protocol requirements. It would not covary like Self does for return types, instead being fixed by the class that declares conformance.<br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class="">To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related #Self literal:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">A further static identifier, </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">#Self</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in. </span></div><div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class=""><p style="box-sizing: border-box; margin-top: 16px; margin-bottom: 16px;" class=""><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">#Self</code> expands to the static type of the code it is declared within. In value types, this is always the same as <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Self</code>. In reference types, it refers to the declaring type. <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">#Self</code> will offer a literal textual replacement just like <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">#file</code>, etc.</p></li></ul></div></blockquote><div class=""><div class="">At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including #Self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.</div></div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>