[swift-evolution] [RFC] #Self

[Matthew Johnson]

Sent from my iPad

> On May 11, 2016, at 10:43 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> 
>> On 11.05.2016 17:42, Matthew Johnson wrote:
>> You are describing the behavior of Self, not #Self.
> 
> Well.. Yes :-) I.e. I wanted to show that `->#Self` requirement in protocol(from my point of view) will produce issues just like `->Self`
> 
> 
>> 
>>>       #Self expands to the static type of the code it is declared
>>> within. In value types, this is always the same as Self. In reference
>>> types, it refers to the *declaring* type.
>> 
>> For implementations of protocol requirements the declaring type is the type
>> that declares conformance.
>> 
>> Self is covariant, #Self (or Type) is invariant.  That is the difference.
> 
> There is some misunderstanding between us.
> Most likely this is because of my terrible English. (Btw, sorry for this)
> 
> I just can't understand, how do you understand the `A` protocol conformance for F & G classes in my examples?
> 
> In your word, with implemented #Self, F & G `is A` ? If so, how exactly they conform to protocol that says F & G *must* have `f` that returns #Self. What is #Self for F & G classes that should be returned in f()?
> Right now I think that your idea just can not be implemented at all based on *initial* #Self proposal.

'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.