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 ;-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
