I'm not quite sure I understand the 'Additional Utility' section. A given class hierarchy can only have one implementation of a given static method; static methods are effectively final. Therefore, the 'Self' introduced in the previous proposal should be completely sufficient for invoking a static method on a class. (Likewise, for moving around code.) In fact, the previous proposal for 'Self' used a very similar example.
I think the example would make more sense if it involved class methods. However, *without considering the protocol applications* I wouldn't consider that a compelling enough use case, by itself, to add StaticSelf. As for StaticSelf's impact on protocols, I defer to the opinions of the other folks who've commented on the thread. Austin > On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > Erica Sadun and I have written a proposal are following up the recent > discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an > invariant Self. > > The recent discussion can be found here: > http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565 > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565> > > The proposal can be found here: > 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> > > We look forward to continuing the discussion. We plan to submit a PR in the > near future after incorporating your final feedback. > > Thanks, > Matthew > Introducing StaticSelf, an Invariant Self > > Proposal: TBD > Authors: Matthew Johnson <https://github.com/anandabits>, Erica Sadun > <https://github.com/erica> > Status: TBD > Review manager: TBD > Introduction > > This proposal introduces a new keyword that provides consistent invariant > type semantics in all contexts. > > The Swift-evolution thread about this topic can be found here: [RFC] #Self > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565> > Motivation > > The distinction between covariant and non-covariant type references come into > play when > conforming non-final classes to protocols. Fixing a protocol requirement to a > covarying type > means that a method returning Self must be overriden by all subclasses in > order to return > the correct, matching type. > > This proposal builds on the covariant construct Self accepted in SE–0068 > <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md> > to introduce an invariant type identifier. It enables protocol declarations > to consistently > refer to a type that is fixed at compile time. This ensures that subclasses > can inherit > protocol implementations without having to re-implement that code at each > level of > inheritance. > > Under this proposal, a new identifier keyword is fixed in use at the point of > protocol conformance > to the static type of that construct. > > class A: MyProtocol > The invariant StaticSelf identifier will always refer to A, unlike Self, > which is covarying and refers to > the type of the actual instance. Since multiple inheritance for non-protocol > types is disallowed, > this establishes this invariant type identifier with no possibility for > conflict. > > Consider the following example, under the current system: > > protocol StringCreatable { > static func createWithString(s: String) -> Self > } > > extension NSURL: StringCreatable { > // cannot conform because NSURL is non-final > // error: method 'createWithString' in non-final class 'NSURL' must return > `Self` to conform to protocol 'A' > } > Introducing a static, invariant version of Self permits the desired > conformance: > > protocol StringCreatable { > static func createWithString(s: String) -> StaticSelf > } > > extension NSURL: StringCreatable { > // can now conform conform because NSURL is fixed and matches the static > // type of the conforming construct. Subclasses need not re-implement > // NOTE: the return type can be declared as StaticSelf *or* as NSURL > // they are interchangeable > static func createWithString(s: String) -> StaticSelf { > // ... > } > } > Additional Utility > > The utility of StaticSelf is not limited to protocols. A secondary use > enables code to refer to the lexical context’s current type without > explicitly mentioning its name. This provides a useful shortcut when > referencing static type members with especially long names and when > re-purposing code between types. > > class StructWithAVeryLongName { > static func foo() -> String { > // ... > } > func bar() { > // ... > let s = StaticSelf.foo() > // > } > } > Detailed Design > > This proposal introduces StaticSelf, a new keyword that may be used in > protocols to refer to the invariant static type of a conforming construct. > StaticSelf may also be used in the lexical context of any type declaration. > In such use, the keyword is identical to spelling out the full name of that > type. > > Impact on existing code > > Being additive, there should be no impact on existing code. > > Alternatives considered > > The keyword is not fixed at this time. Alternatives that have been discussed > include StaticType, InvariantSelf, SelfType, or Type. The community is > welcome to bikeshed on the most clear and concise name for this keyword. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
