> On May 30, 2016, at 5:22 AM, Charles Srstka via swift-evolution
> <[email protected]> wrote:
>
>> On May 29, 2016, at 10:13 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On May 29, 2016, at 9:43 PM, Charles Srstka <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>> On May 29, 2016, at 9:20 PM, Matthew Johnson <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>>> On May 29, 2016, at 5:16 PM, Austin Zheng <[email protected]
>>>>>> <mailto:[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).
not that simple. see further down.
>>>>>
>>>>> 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.
>
> 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’ve been wondering about that one because of this:
/// Whether the existential of this protocol conforms to itself.
unsigned ExistentialConformsToSelf : 1;
but in the end it is false for non obj-c protocols (which eliminates the Struct
in the example). but there are still more rules
> Charles
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
