Sent from my iPad
> On May 29, 2016, at 10:22 PM, Charles Srstka <[email protected]> wrote: > >> On May 29, 2016, at 10:13 PM, Matthew Johnson <[email protected]> wrote: >> >> On May 29, 2016, at 9:43 PM, Charles Srstka <[email protected]> wrote: >> >>>> On May 29, 2016, at 9:20 PM, Matthew Johnson <[email protected]> >>>> wrote: >>>> >>>> On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution >>>> <[email protected]> wrote: >>>> >>>>>> On May 29, 2016, at 5:16 PM, Austin Zheng <[email protected]> wrote: >>>>>> >>>>>> I think the problem here is that P == P is true, but P : P is not (a >>>>>> protocol does not conform to itself). >>>>> >>>>> But if you have a variable, parameter, etc. typed as P, that’s *not* the >>>>> protocol, since protocols aren’t concrete entities. What you have there, >>>>> by definition, is something that conforms to P. Similarly, something like >>>>> [P] is just a collection of things, perhaps of various types, which all >>>>> have the common feature that they conform to P. >>>> >>>> You have an existential value of type P. It is a well known frustration >>>> in Swift that the existential type corresponding to a protocol does not >>>> conform to the protocol. This has been discussed off and on at different >>>> times. >>>> >>>> There are a couple of reasons this is the case. IIRC in some cases it >>>> actually isn't possible for the existential to conform to the protocol in >>>> a sound way. And even when it is possible, I believe it has been said >>>> that it is more difficult to implement than you might think. Hopefully >>>> the situation will improve in the future but I'm not aware of any specific >>>> plans at the moment. >>> >>> It’s been my understanding that a variable typed P in swift is equivalent >>> to what we would have called id <P> in Objective-C—that is, an object of >>> unknown type that conforms to P. Is this not the case? I am curious what >>> the conceptual difference would be, as well as the rationale behind it. >> >> Existentials have their own type in Swift. The problem you are running into >> is because the generic constraint is looking at the existential type of P >> and asking if that type conforms to P (which it does not - you can't write >> the conformance and the compiler does not provide it for you). It is not >> asking if the type of the object underlying the existential value conforms >> to P (which it necessarily does). When you have a value of type P you have >> already erased the type of the underlying object. > > Have we not also erased the type of the underlying object with id <P>, > though? The only thing we get from the “id” is that it’s an Objective-C > object of some type, which it would have to have been anyway in order to > conform to the protocol in the first place. Thus the type of the object is > erased, and the only thing we know about it is that it conforms to the > protocol—just like something typed P in Swift. In Swift values with the existential type P are not necessarily objects, they could be values. Because of this existentials are implemented a bit differently. > > What I’m trying to figure out is whether there’s any positive benefit or > rationale to the reason things work the way they do here, or whether it’s > just bugs / implementation details. I think it's a bit of both. As I mentioned, IIRC there are cases where values of existential type *cannot* correctly conform to the protocol that they were derived from (I believe this is when Self or associated type requirements are involved). There are also cases where it is possible but is more difficult to implement than you might expect. I think we'll see progress eventually, but not in Swift 3. > > Charles >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
