Thank you for answers, just to clarify:

On 10.05.2016 18:47, Matthew Johnson wrote:

On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution
<[email protected]> wrote:

What about #Self in protocols? I.e. is it proposed to have #Self in
protocols, where conformance will require a substitution by real type
name?

protocol A { func a() -> Self func b(c: Self) // b(c: #Self)   ? }

Self and #Self are different for non-final classes.  In protocol
requirements Self would covary and #Self would be fixed by the class
that provides conformance.  The distinction is pretty subtle and is

protocol A { func a() -> Self func b(c: #Self) }

Yes, Self and #Self sometimes is not the same, and sometimes is the same.
Here I asked about b() method. No questions regarding a() method.

So, after #Self will be introduced, this definition will be correct:

protocol A {
        func a() -> Self
        func b(c: #Self)
}

and be exactly the same as

protocol A {
        func a() -> Self
        func b(c: Self)
}

Will both variants coexist? I'd prefer compiler to be strict in this case and allows only #Self in b() method, as this is more correct and explicit declaration, i.e. func b(c: Self) in protocol A really means func b(c: #Self). No?



class C: A { func a() -> Self { return self } func b(c: C) {} // b(c:
#Self) ? }

C is non-final so we must be careful.  C and #Self both refer to the
same thing.  Self covaries and would thus refer to the dynamic type of
the instance in both signatures and bodies.  This means that a method
returning Self must be overridden by all subclasses in order to return
the correct type.

Yes, I believe it is all clear with a() method. This is why I placed the commend with #Self for `b` method only


One of the advantages of allowing #Self in protocol requirements is that
it is one way to solve a problem that has receive significant discussion
on the list in the past: retroactively conforming non-final classes to
protocols with factory methods that do not need to covary.  There is no
way to express a this kind of requirement in the language today.


Could you please illustrate this in a couple lines of code? Just to fully understand.



protocol A2 { var a: Self {get} }

final class C2 : A2 { var a: C2 { return C2() } // #Self { return
#Self() }  ? }

In final classes and value types the type name itself (C2 in this
example), Self, and #Self would all reference the same thing.


Exactly in my example, you can't use `Self` keyword in class:

final class C2 : A2 {
    var a: Self { return Self() } // error
}

but I expect to be able to have:

final class C2 : A2 {
    var a: #Self { return #Self() }
}


On 10.05.2016 17:50, Erica Sadun via swift-evolution wrote:
As a compile-time substitution, it could be used in any and all of
the examples in your bullet list as a literal text replacement..

Quick rundown:

struct A { ...#Self... // #Self is substituted by A }

class B { ...#Self... // Self is substituted by B }

class C { ... #Self... // Self is substituted by C, which is the
defining type at compile time }

I'm stepping away from endorsing or pushing this forward. If you
want to pick this up and run with it, it's yours.

-- E


On May 10, 2016, at 8:34 AM, Matthew Johnson
<[email protected] <mailto:[email protected]>> wrote:

Can you clarify where would #Self would be allowed?

* property declarations * method signatures * method and computed
property bodies * all of the above

I would like to see this and allowed in all of the above.

We should also consider allowing this in protocol requirements.
It would not covary like Self does for return types, instead being
fixed by the class that declares conformance.

Sent from my iPad

On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution
<[email protected] <mailto:[email protected]>>
wrote:

To focus SE-0068 and narrow its scope, I removed the `#Self`
part of the proposal. This offered compile-time substitution of
the defining type for a related #Self literal:

A further static identifier, |#Self| expands to static type of
the code it appears within, completing the ways code may want to
refer to the type it is declared in.

*

|#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. |#Self| will
offer a literal textual replacement just like |#file|, etc.

At Chris's suggestion, I'm starting a new SE thread to see
whether there remains any interest for including #Self in the
language. I'm personally happy with the SE-0068 outcome but I
didn't want to undercut anyone like Timothy Wood who had
originally spoken up for its inclusion.

-- E

_______________________________________________ swift-evolution
mailing list [email protected]
<mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution



_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution


_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to