[swift-evolution] [RFC] #Self

Matthew Johnson matthew at anandabits.com
Wed May 11 13:31:19 CDT 2016

Sent from my iPad

> On May 11, 2016, at 11:43 AM, Vladimir.S <svabox at gmail.com> 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.

More information about the swift-evolution mailing list