That explanation is succinct and cogent. I can see the need for this proposed behavior. Having just played around with conforming classes to protocols, I think #Self is rather clear, but Type would be a little mystifying.
On Wed, May 11, 2016 at 08:43 Matthew Johnson via swift-evolution < [email protected]> wrote: > > > Sent from my iPad > > > On May 11, 2016, at 1:22 AM, Vladimir.S <[email protected]> wrote: > > > > > No, class would not need to be final to conform to a requirement > returning #Self. The difference is that with Self covaries and #Self does > not. This means you *do not need* to guarantee that all subclasses > override a requirement that returns #Self, while you do need to guarantee > that all subclasses override a requirement that returns Self. > > > > I'm probably slow these day, but I(and probably someone else) just can't > understand this. Thank you for your patience in explaining this: > > Just after you conforms *base* class to *any* protocol, any possible > subclass *must* (you *have to* guarantee this) conform the same protocol. > > > > class A {..} > > class B:A {..} > > class C:A {..} > > protocol D {..} > > extension A: D {} > > -> now B&C and any other existed and *possible* subclass *must* conforms > to the same protocol D just because of inheritance. As soon as they are > subclass of A, they *must* be `is D` and *must* have the methods that > return #Self. No? > > Yes, they must and will conform. The distinction is that if the protocol > has requirements returning Self all subclasses must override those > requirements and to return their type because the inherited implementation > returns their supertype. With #Self (or Type as we're now calling it) they > would not need to override those requirements because the ancestor that > initially declared conformance provides an inherited implementation that > remains valid for all of its descendants. > > > > >> On 10.05.2016 22:04, Matthew Johnson wrote: > >> > >>> On May 10, 2016, at 1:38 PM, Vladimir.S <[email protected]> wrote: > >>> > >>> On 10.05.2016 20:50, Matthew Johnson wrote: > >>>> No, the whole point is that D.f() returns C because C is the > requirement > >>>> of 'f' is declared to return #Self which is C where the protocol > >>>> conformance is declared and implemented. If you want a covariant > >>>> requirement you would use Self as the return type, not #Self. > >>> > >>> I just followed your example with NSURL.. Probably I don't understand > the point, but you said you want to conform a non-final class to protocol > with method -> #Self. > >>> > >>>> ---------------------< > >>> protocol A { static func createWithString(s: String) -> Self } > >>> extension NSURL: A { // cannot conform because NSURL is non-final } > >>> > >>> If we could define a protocol requirement that didn't covary (using > >>> #Self or whatever) we would be able to write the desired conformance. > >>>> ---------------------< > >>> > >>> And I don't understand how do you want to achieve the target, as even > if we 'invent' #Self, this (as I understand) can't work as class is not > final. Just like with 'simple' Self - class must be final to conform. Thank > you for clarification. > >> > >> No, class would not need to be final to conform to a requirement > returning #Self. The difference is that with Self covaries and #Self does > not. This means you do not need to guarantee that all subclasses override > a requirement that returns #Self, while you do need to guarantee that all > subclasses override a requirement that returns Self. > >> > >> The requirement to guarantee that all subclasses provide this override > is the reason you cannot declare conformance in the case of requirements > returning Self. Since this isn’t necessary for #Self (will probably have a > different name) the class does not need to be final in order to conform. > >> > >> -Matthew > >> > >> . > >> > > _______________________________________________ > 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
