Sent from my iPad
> On May 11, 2016, at 7:33 AM, Thorsten Seitz <tseit...@icloud.com> wrote:
>
>
>
>> Am 10. Mai 2016 um 20:11 schrieb Matthew Johnson <matt...@anandabits.com>:
>>
>>
>>
>> Sent from my iPad
>>
>>>> On May 10, 2016, at 12:59 PM, Thorsten Seitz <tseit...@icloud.com> wrote:
>>>>
>>>>
>>>>> Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution
>>>>> <swift-evolution@swift.org>:
>>>>>
>>>>>
>>>>> On May 10, 2016, at 9:28 AM, Matthew Johnson <matt...@anandabits.com>
>>>>> wrote:
>>>>> Yep, understood. It's perfectly clear to me but I understand why Chris is
>>>>> concerned about it having potential to confuse people. It is a pretty
>>>>> subtle difference especially since Self and #Self are the same in some
>>>>> contexts. In any case, I would be content to live with any name that wins
>>>>> out.
>>>>
>>>> Ah, OK -- it sounds like we just differ on what would be least confusing =)
>>>>
>>>> The other proposed name of #StaticSelf, seems like it would be very clear
>>>> (if a bit redundant and longer than needed, once you’ve come across it
>>>> once or twice). I could certainly live with #StaticSelf.
>>>
>>> In that case StaticSelf would be sufficient IMHO. The # should only be
>>> needed to distinguish between Self and #Self.
>>>
>>> So:
>>>
>>> Self, #Self
>>> Self, StaticSelf
>>> DynamicSelf, StaticSelf
>>>
>>>
>>> As far as I understand #Self should be the type of the implementor
>>> (ImplementorSelf?) or conforming type (ConformingSelf?).
>>> How would this work with default methods?
>>>
>>> protocol A {
>>> func f() -> #Self
>>> init()
>>> }
>>>
>>> extension A {
>>> func f() -> #Self { return init() } // what type has #Self here?
>>> }
>>
>> The conforming type. C in your example. If we have 'class D: C' and it
>> overrides 'f' the override would have a return type of C, not D. The
>> returned instance could be of type D since it is a subtype of C. We could
>> also explore allowing overrides to have a covariant return type, it just
>> wouldn't be visible when accessed via the protocol through a generic
>> constraint or an existential (those would only guarantee C, the type that
>> declared the conformance.
>
>
> Thanks, that makes sense.
> So within a default method like in extension A above the (concrete) type of
> #Self is still unknown and I only know that it will conform to A. That's
> fine. As soon as a non protocol type like a class conforms to the protocol
> #Self gets fixed to that type and because we have no multiple inheritance for
> non protocols there is no possibility to create conflicts.
Yep, it's a pretty subtle distinction from Self but will be useful to have.
>
> -Thorsten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
