> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution
> <[email protected]> wrote:
>
>
>
> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution
> <[email protected] <mailto:[email protected]>>:
>
>> I agree; the difference between protocols with and without associated types
>> has been an endless source of confusion for a lot of people.
>>
>> Speaking of which, for those who care I rewrote the draft proposal to
>> attempt a much more rigorous treatment of the semantics of the generalized
>> existential, including a discussion about existential type equivalence and
>> subtyping. It would be nice to see people poke holes in my logic so I can
>> patch them up.
>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md
>>
>> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md>
> I think that *all* methods should be available - at least in principle - with
> associated types
> - replaced by their upper bounds (i.e. Any if no constraints have been given
> either by the protocol definition itself or th existential) if in covariant
> position and
> - replaced by their lower bounds if in contravariant position
>
> As it is not possible to define lower bounds in Swift, the lower bounds are
> always the bottom type (called `Nothing` in Swift and not be confused with
> optionals). The bottom type has no members and therefore a method referencing
> that type cannot be called and is effectively not available.
Called `Nothing` in Swift? Where do you get that? `func foo(s: Nothing) {}`
gives me “use of undeclared type `Nothing`”. If Swift had a bottom type
wouldn’t we be able to declare a function accepting an argument of type
`Nothing` (we could just never call it because we couldn’t construct an
argument).
>
> -Thorsten
>
>>
>> Austin
>>
>>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> I agree with this. If we're certain we should reskin protocol<> as Any<>,
>>>> we should frontload that change—in addition to affecting source code, it'd
>>>> also influence the runtime behavior of type printing/parsing, which can't
>>>> be statically migrated in the future. I think any discussion of extending
>>>> existentials has to be considered out of scope for Swift 3, though, so the
>>>> Any rename deserves its own proposal.
>>>>
>>>> -Joe
>>>
>>>
>>> Its really unfortunate that the generics work is probably going to be
>>> deferred. When you really dive in to protocol-oriented programming and
>>> designing frameworks to be native Swift (taking advantage of Swift
>>> features) the existential problem comes up a lot and leads to sub-optimal
>>> designs, abandonment of type safety, or gobs of boilerplate.
>>>
>>>
>>> Russ
>>>
>>> _______________________________________________
>>> 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] <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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
