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

[Vladimir.S]

I don't understand.
Right now we are allowed to have Optional(Self) :

protocol A {
   func g()->Self?
}

class B: A {
   func g()->Self? {return self}
}

print(B().g()) //Optional(main.B)

How do you want to divide your `->Self?` and this currently possible 
`->Self?` ?


But I do like the idea to separate meaning of `Self` in protocol with some 
marker.. What about `->?Self` and `->!Self` - no confusing with Optional<>

On 13.05.2016 14:21, LM via swift-evolution wrote:
>
> 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 <laurent.mihalkovic at gmail.com
> <mailto:laurent.mihalkovic at gmail.com>> 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
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>