Sent from my iPad
> On May 11, 2016, at 7:33 AM, Thorsten Seitz <[email protected]> wrote: > > > >> Am 10. Mai 2016 um 20:11 schrieb Matthew Johnson <[email protected]>: >> >> >> >> Sent from my iPad >> >>>> On May 10, 2016, at 12:59 PM, Thorsten Seitz <[email protected]> wrote: >>>> >>>> >>>>> Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution >>>>> <[email protected]>: >>>>> >>>>> >>>>> On May 10, 2016, at 9:28 AM, Matthew Johnson <[email protected]> >>>>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
