<html><body><div>Am 13. Mai 2016 um 09:36 schrieb "Vladimir.S via swift-evolution" <swift-evolution@swift.org>:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">Why did you decide to drop the `#` ? As `StaticSelf` will be resolved on <br>compilation time like #file etc ? I feel like this is inconsistent solution.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span># is not needed just like it is not needed for generic type parameters which are also resolved at compilation time. </span></div><div><span>#file etc. insert information about artefacts outside of the language (i.e. the name of the file wherein the code resides) which is very different.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>-Thorsten</span></div><div><span><br data-mce-bogus="1"></span></div><div><span><br></span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>Also, do you expect this will work:<br><br>protocol A {<br> func g()->StaticSelf<br>}<br><br>class B: A {<br> func g()->StaticSelf {return B()}<br>}<br><br>class C: B {<br> //func f(s: C) {}<br>}<br><br>func x(a: A ){<br> var xx : A = a.g() // ?<br> print(xx)<br>}<br><br>func z<T: A>(t: T) {<br> let u = t.g() // ?<br> print(u)<br>}<br><br>let c = C()<br>z(c)<br>x(c)<br><br><br>On 13.05.2016 3:49, Matthew Johnson via swift-evolution wrote:<br><blockquote type="cite" class="quoted-plain-text">Erica Sadun and I have written a proposal are following up the recent</blockquote><blockquote type="cite" class="quoted-plain-text">discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an</blockquote><blockquote type="cite" class="quoted-plain-text">invariant Self.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The recent discussion can be found</blockquote><blockquote type="cite" class="quoted-plain-text">here: <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565" data-mce-href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565">http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565</a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The proposal can be found</blockquote><blockquote type="cite" class="quoted-plain-text">here: <a href="https://github.com/anandabits/swift-evolution/blob/static-self/proposals/NNNN-static-self.md" data-mce-href="https://github.com/anandabits/swift-evolution/blob/static-self/proposals/NNNN-static-self.md">https://github.com/anandabits/swift-evolution/blob/static-self/proposals/NNNN-static-self.md</a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">We look forward to continuing the discussion. We plan to submit a PR in</blockquote><blockquote type="cite" class="quoted-plain-text">the near future after incorporating your final feedback.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Thanks,</blockquote><blockquote type="cite" class="quoted-plain-text">Matthew</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Introducing StaticSelf, an Invariant Self</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">* Proposal: TBD</blockquote><blockquote type="cite" class="quoted-plain-text">* Authors: Matthew Johnson <<a href="https://github.com/anandabits>" data-mce-href="https://github.com/anandabits>">https://github.com/anandabits></a>, Erica Sadun</blockquote><blockquote type="cite" class="quoted-plain-text"><<a href="https://github.com/erica>" data-mce-href="https://github.com/erica>">https://github.com/erica></a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text">* Status: TBD</blockquote><blockquote type="cite" class="quoted-plain-text">* Review manager: TBD</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Introduction</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">This proposal introduces a new keyword that provides consistent invariant</blockquote><blockquote type="cite" class="quoted-plain-text">type semantics in all contexts.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">/The Swift-evolution thread about this topic can be found here: [RFC] #Self</blockquote><blockquote type="cite" class="quoted-plain-text"><<a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565>/" data-mce-href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565>/">http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565>/</a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Motivation</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The distinction between covariant and non-covariant type references come</blockquote><blockquote type="cite" class="quoted-plain-text">into play when</blockquote><blockquote type="cite" class="quoted-plain-text">conforming non-final classes to protocols. Fixing a protocol requirement to</blockquote><blockquote type="cite" class="quoted-plain-text">a covarying type</blockquote><blockquote type="cite" class="quoted-plain-text">means that a method returning |Self| must be overriden by all subclasses in</blockquote><blockquote type="cite" class="quoted-plain-text">order to return</blockquote><blockquote type="cite" class="quoted-plain-text">the correct, matching type.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">This proposal builds on the covariant construct |Self| accepted in SE–0068</blockquote><blockquote type="cite" class="quoted-plain-text"><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>" data-mce-href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>">https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md></a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text">to introduce an invariant type identifier. It enables protocol declarations</blockquote><blockquote type="cite" class="quoted-plain-text">to consistently</blockquote><blockquote type="cite" class="quoted-plain-text">refer to a type that is fixed at compile time. This ensures that subclasses</blockquote><blockquote type="cite" class="quoted-plain-text">can inherit</blockquote><blockquote type="cite" class="quoted-plain-text">protocol implementations without having to re-implement that code at each</blockquote><blockquote type="cite" class="quoted-plain-text">level of</blockquote><blockquote type="cite" class="quoted-plain-text">inheritance.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Under this proposal, a new identifier keyword is fixed in use /at the point</blockquote><blockquote type="cite" class="quoted-plain-text">of protocol conformance/</blockquote><blockquote type="cite" class="quoted-plain-text">to the static type of that construct.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">|class A: MyProtocol|</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The invariant |StaticSelf| identifier will always refer to |A|,</blockquote><blockquote type="cite" class="quoted-plain-text">unlike |Self|, which is covarying and refers to</blockquote><blockquote type="cite" class="quoted-plain-text">the type of the actual instance. Since multiple inheritance for</blockquote><blockquote type="cite" class="quoted-plain-text">non-protocol types is disallowed,</blockquote><blockquote type="cite" class="quoted-plain-text">this establishes this invariant type identifier with no possibility for</blockquote><blockquote type="cite" class="quoted-plain-text">conflict.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Consider the following example, under the current system:</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">|protocol StringCreatable { static func createWithString(s: String) -> Self</blockquote><blockquote type="cite" class="quoted-plain-text">} extension NSURL: StringCreatable { // cannot conform because NSURL is</blockquote><blockquote type="cite" class="quoted-plain-text">non-final // error: method 'createWithString' in non-final class 'NSURL'</blockquote><blockquote type="cite" class="quoted-plain-text">must return `Self` to conform to protocol 'A' }|</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Introducing a static, invariant version of |Self| permits the desired</blockquote><blockquote type="cite" class="quoted-plain-text">conformance:</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">|protocol StringCreatable { static func createWithString(s: String) -></blockquote><blockquote type="cite" class="quoted-plain-text">StaticSelf } extension NSURL: StringCreatable { // can now conform conform</blockquote><blockquote type="cite" class="quoted-plain-text">because NSURL is fixed and matches the static // type of the conforming</blockquote><blockquote type="cite" class="quoted-plain-text">construct. Subclasses need not re-implement // NOTE: the return type can be</blockquote><blockquote type="cite" class="quoted-plain-text">declared as StaticSelf *or* as NSURL // they are interchangeable static</blockquote><blockquote type="cite" class="quoted-plain-text">func createWithString(s: String) -> StaticSelf { // ... } }|</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Additional Utility</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The utility of |StaticSelf| is not limited to protocols. A secondary use</blockquote><blockquote type="cite" class="quoted-plain-text">enables code to refer to the lexical context’s current type without</blockquote><blockquote type="cite" class="quoted-plain-text">explicitly mentioning its name. This provides a useful shortcut when</blockquote><blockquote type="cite" class="quoted-plain-text">referencing static type members with especially long names and when</blockquote><blockquote type="cite" class="quoted-plain-text">re-purposing code between types.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">|class StructWithAVeryLongName { static func foo() -> String { // ... } func</blockquote><blockquote type="cite" class="quoted-plain-text">bar() { // ... let s = StaticSelf.foo() // } }|</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Detailed Design</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">This proposal introduces |StaticSelf|, a new keyword that may be used in</blockquote><blockquote type="cite" class="quoted-plain-text">protocols to refer to the invariant static type of a conforming</blockquote><blockquote type="cite" class="quoted-plain-text">construct. |StaticSelf| may also be used in the lexical context of any type</blockquote><blockquote type="cite" class="quoted-plain-text">declaration. In such use, the keyword is identical to spelling out the full</blockquote><blockquote type="cite" class="quoted-plain-text">name of that type.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Impact on existing code</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Being additive, there should be no impact on existing code.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Alternatives considered</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">The keyword is not fixed at this time. Alternatives that have been</blockquote><blockquote type="cite" class="quoted-plain-text">discussed include |StaticType|, |InvariantSelf|, |SelfType|, or |Type|. The</blockquote><blockquote type="cite" class="quoted-plain-text">community is welcome to bikeshed on the most clear and concise name for</blockquote><blockquote type="cite" class="quoted-plain-text">this keyword.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">_______________________________________________</blockquote><blockquote type="cite" class="quoted-plain-text">swift-evolution mailing list</blockquote><blockquote type="cite" class="quoted-plain-text"><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br data-mce-bogus="1"></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></div></body></html>