Sent from my iPad
> On May 23, 2016, at 12:26 PM, Robert Widmann <[email protected]> wrote: > > The fun part about Nothing (⊥) is that it does have one constructor: crashing. Ok, but where does the part about calling bottom 'Nothing' in Swift come from? This is the first I've heard of the name 'Nothing' in Swift. > > ~Robert Widmann > > 2016/05/23 10:17、Matthew Johnson via swift-evolution > <[email protected]> のメッセージ: > >> >>> 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]>: >>>> >>>> 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 >>> >>> 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]> wrote: >>>>>> >>>>>> >>>>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution >>>>>> <[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] >>>>> 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 >> >> _______________________________________________ >> 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
