[swift-evolution] [RFC] #Self

Xiaodi Wu xiaodi.wu at gmail.com
Wed May 11 10:19:54 CDT 2016


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 <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> > On May 11, 2016, at 1:22 AM, Vladimir.S <svabox at gmail.com> 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 <svabox at gmail.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/eccc15b0/attachment.html>


More information about the swift-evolution mailing list