Considering the precedent of using ! and ? in swift, could it be that: Self! would designate what is known for sure, the invariant compile time type of self
Self? Would designate the yet unknown (*optional* if you will) covariant type of self Regards LM (From mobile) > On May 13, 2016, at 3:59 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > I like the way the motivation for this feature has been explained here. Now > that the reasoning behind it is evident, I have to say I'm leaning towards > the "InvariantSelf" name--after all, you describe this feature in the title > as "an invariant self." > > >> On Thu, May 12, 2016 at 7: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 >> >> The proposal can be found here: >> 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, Erica Sadun >> 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 >> >> 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 >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
