[swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Xiaodi Wu]

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 <
swift-evolution at swift.org> 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 <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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/fc4cd932/attachment.html>