The other advantage of Self! over StaticSelf is that in code completion, Self, Self? Self! Will come together, giving people a quick tool to discover/remind themselves of the semantic difference right at the point of use.
It might also address Joe's comment about StaticSelf not being much of a shortcut. > On May 13, 2016, at 1:15 PM, LM <[email protected]> wrote: > > 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
