[swift-evolution] [RFC] #Self

[Vladimir.S]

Inline

On 12.05.2016 18:36, Matthew Johnson wrote:
>> I believe, for clarity, after we introduce #Self(or whatever name it will
>> have) we need to require `#Self` in protocol as type of method parameter:
>>
>> protocol A {
>>  func f1() -> Self // this could be Self and could be #Self
>
> What in the original proposal makes you think Self and #Self would be
> interchangeable here?  Again, the proposal was for #Self to be invariant.
>  Self is covariant.  Those are very different things.

Just incorrect comment for my code. Please add in mind *in implementation* 
to the end of the comment. I don't mean that they can be interchangeable in 
protocol definition, no, I mean at the moment of implementation `->Self` 
could became `->Self` or `->#Self` depending on where it will be 
implemented. Examples of implementation was below.

>
> The semantics in the original proposal were unspecified with regards to
> protocols.  I am simply extending it to retain the invariant semantics that
> the proposal *did* specified when it is used as a protocol requirement.
>

IMO your suggestion can not be coupled with initial proposal.
And I mean the recent(last) proposal in email I quoted in one of previous 
message, where nothing was said regarding protocols.

...
>> let a : A = Derived2()
>> let some = a.f() // you expect some.dynamicType is Derived2
>
> The protocol specifies #Self (or Type, which we are not calling it).  It is
> conformed to by Base.  This means the return type of `f` is only guaranteed
> to be Base.  It *may* be Derived2, but it need not be.  Obviously given
> this example we know it is Derived2 because we can see the implementation
> but the type system does not.  This means `some` has type of Base.  Its
> dynamicsType *may* be Derived2 (and again in this case we can see that it
> will be) but that is not guaranteed by the type system.
>

I'm tired ;-)
You are trying to couple two IMO different things.
`#Self` as parameter's type in protocol and inside class/struct means 
'placeholder for exactly this concrete type name in implementation'. Not 
base class!
I can't understand how you can extend this meaning to "derived class 
conforms to ->#Self, but returns some base class".

> What you are missing is that #Self is not the same as Self.  It is
> invariant.  A was originally conformed to by Base.  The requirement is
> invariant and becomes fixed by the conformance declaration.  In this case
> it is fixed to Base.

Again. I'm not missing this. It is clear they are no the same. Please point 
where exactly I missed this.
But you are trying to use the same keyword `#Self`(or Type,not important) 
in meaning 'this concrete type' and in 'this or base type'.

>
> You have not explained why you think #Self should be invariant when used in
> a type context and covariant when used in a protocol context.  This
> expectation is what is confusing you.  If you really what that semantic I
> think the burden is on you to make the case that we need something with
> this mixed semantic.  I think it is much more confusing than having
> separate constructs for covariant and invariant semantics.

Just because of meaning(description) of #Self in initial proposal and its 
behavior at the implementation side(inside type body).

If you extend the meaning of your `#Self` to 'any type in hierarchy of that 
type', that I can understand.

> Again, what you are calling SelfOrBase is *exactly* what I am calling Type
> (or #Self).  It has consistent invariant semantics in all contexts.

Again ;-), Yes. And I'm against to name your 'thing' with the same name as 
#Self(or Type) because they mean different things, different behavior.

Actually I think I got your points, I can't accept them and it seems like 
there is no some 'common' solution. You think that it is OK to have 
`->#Self` in protocol requirements in meaning "self of any base class", but 
I can't accept and understand this.

Thank you for discussion, probably I need to re-think all of this and find 
out that I was not right. I'll let then know ;-)