Sent from my iPad
> On May 11, 2016, at 11:43 AM, Vladimir.S <[email protected]> wrote: > > Well, I believe I understand now what *you mean* under #Self. OK. Thank you > for clarifications. > In my terminology 'this' could be called BaseSelf. Your "thing" just can not > be called #Self. > IMO in initial proposal #Self means not more than placeholder for the > concrete type name(inside type declaration or inside protocol). > > You propose just something different, more advanced than initial #Self, you > propose not some static "thing" but extended behavior if #Self is a return > type of protocol requirement. > > I strictly against to couple the initial proposal of #Self and your proposal > for extended features (for protocol conformance of `->#Self`). > Please be clear and obvious regarding the name of that feature. I really > think the behavior you propose can not be called #Self(or Type) > > What I suggest: de-couple these proposals to: > > a) initial proposal of #Self as placeholder for concrete type name. Choose > the name for it. Probably StaticSelf, or Type, or somehting else > > b) your proposal for BaseSelf feature. I'll definitely support it with just > name changed to clearly reflect its propose. I don't believe the initial proposal stated how it would behave in a protocol. However I do believe the feature I am talking about covers all of the use cases Erica had in mind while also providing useful semantics when used in a protocol requirement. Erica, please correct me if I'm wrong. You want to make the semantics of #Self / Type be covariant when used in a protocol requirement. This makes no sense to me as it is explicitly *not* covariant when used within a class declaration. We already have a covariant construct (Self) and the proposal is to introduce an invariant construct (#Self or Type). The invariant semantic should be consistent regardless of whether it is used in a protocol requirement or a type declaration. IMO BaseSelf is a poor choice of name for something that is supposed to be valid syntax in value types as well as classes. > >> On 11.05.2016 18:58, Matthew Johnson wrote: >> 'f' would return E for E, F and G. Because the conformance is declared >> by E the requirement to return #Self is fixed as an invariant >> requirement to return E for all potential subclasses. >> >>>> >>>> Probably you(we) need another proposal, like BaseSelf (or SuperSelf) >>>> that means "this class or any its base class", then I understand how >>>> such a `f()->BaseSelf` protocol requirement can be applied to E >>>> class and also be true for F&G classes (as f() inherited from base >>>> class will return instance of E which is base for both). >> This is exactly what #Self (or Type) does. The behavior you have been >> describing is the behavior of Self which already exists. >> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
