I'll add it to the "Future Directions" section. I feel that's the best place to put it, since there's no guarantee that Swift will get a bottom type, and because making existentials to work with a bottom type would be a completely additive change.
Austin > On May 29, 2016, at 12:48 PM, Thorsten Seitz <[email protected]> wrote: > >> >> Am 29.05.2016 um 18:07 schrieb Austin Zheng <[email protected] >> <mailto:[email protected]>>: >> >> >>> On May 29, 2016, at 7:04 AM, Matthew Johnson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> This makes a lot more sense! So you want to be able to use uninhabitable >>> types in the contexts of things like collection elements (such collections >>> must always be empty but are inhabitable by a single empty instance). It >>> is a great example of why it might make sense to allow types like this. >>> >>> What you are really asking for is the ability to drop the restriction that >>> only a single superclass constraint is allowed and no value type >>> constraints are allowed. It might be useful in cases like your >>> intersection example. But it could also be a source of error confusing >>> error messages when people form such a type and it doesn't work the way >>> they expect. If the type is disallowed as under the current proposal the >>> error message might be more straightforward. This is a topic that probably >>> deserves further consideration. But I have to say I find your intersection >>> example to be reasonably compelling. >>> >>> Austin, what do you think about this example? >> >> I personally don't feel like the additional complexity is worth it as Swift >> exists today. > > I agree that adding a bottom type would be a different proposal. As an > intermediate step we could just make it a type error if an existential would > only be satisfied by the bottom type. > > -Thorsten > > >> >> Swift getting a real bottom type would be a completely different proposal. >> It would allow you to do things like: >> >> let universalNil : Bottom? = nil >> var a : Int? = universalNil >> var b : UIView? = universalNil >> >> and so on. >> >> If Swift does ever get such a type relaxing the restriction from the >> proposal would be an additive change, and could be proposed separately as a >> follow up addition. >> >> Austin >> >> >>> >>>> >>>> -Thorsten >>>> >>>> >>>>> >>>>> To write this `union` and have it behave in the usual way you need >>>>> `Any<A, B>` to be a supertype of `A` and of `B`. The existential doesn’t >>>>> actually do that so it would not be possible for this union function to >>>>> guarantee the result would have all of the members of `x` and all the >>>>> members of `y` the way that a `union` usually would. >>>>> >>>>> The anonymous union type `A | B` *is* a supertype of `A` and a supertype >>>>> of `B` so you would have no trouble writing this: >>>>> >>>>> func union<A, B>(x: Set<A>, y: Set<B>) -> Set<A | B> { … } >>>>> >>>>> And returning the expected result. >>>>> >>>>>> >>>>>> >>>>>> -Thorsten >>>>>> >>>>>> >>>>>> >>>>>>> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>> >>>>>>> The inimitable Joe Groff provided me with an outline as to how the >>>>>>> design could be improved. I've taken the liberty of rewriting parts of >>>>>>> the proposal to account for his advice. >>>>>>> >>>>>>> It turns out the runtime type system is considerably more powerful than >>>>>>> I expected. The previous concept in which protocols with associated >>>>>>> types' APIs were vended out selectively and using existentials has been >>>>>>> discarded. >>>>>>> >>>>>>> Instead, all the associated types that belong to an existential are >>>>>>> accessible as 'anonymous' types within the scope of the existential. >>>>>>> These anonymous types are not existentials - they are an anonymous >>>>>>> representation of whatever concrete type is satisfying the >>>>>>> existential's value's underlying type's associated type. >>>>>>> >>>>>>> This is an enormous step up in power - for example, an existential can >>>>>>> return a value of one of these anonymous associated types from one >>>>>>> function and pass it into another function that takes the same type, >>>>>>> maintaining perfect type safety but without ever revealing the actual >>>>>>> type. There is no need anymore to limit the APIs exposed to the user, >>>>>>> although there may still exist APIs that are semantically useless >>>>>>> without additional type information. >>>>>>> >>>>>>> A set of conversions has also been defined. At compile-time 'as' can be >>>>>>> used to turn values of these anonymous associated types back into >>>>>>> existentials based on the constraints defined earlier. 'as?' can also >>>>>>> be used for conditional casting of these anonymously-typed values into >>>>>>> potential actual types. >>>>>>> >>>>>>> As always, the link is here, and feedback would be greatly appreciated: >>>>>>> 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> >>>>>>> >>>>>>> Best, >>>>>>> Austin >>>>>>> >>>>>>> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> >> One initial bit of feedback - I believe if you have existential >>>>>>> >> types, I believe you can define Sequence Element directly, rather >>>>>>> >> than with a type alias. e.g. >>>>>>> >> >>>>>>> >> protocol Sequence { >>>>>>> >> associatedtype Element >>>>>>> >> associatedtype Iterator: any<IteratorProtocol where >>>>>>> >> IteratorProtocol.Element==Element> >>>>>>> >> associatedtype SubSequence: any<Sequence where Sequence.Element == >>>>>>> >> Element> >>>>>>> >> … >>>>>>> >> } >>>>>>> > >>>>>>> > That's not really the same thing. Any<IteratorProtocol> is an >>>>>>> > existential, not a protocol. It's basically an >>>>>>> > automatically-generated version of our current `AnyIterator<T>` type >>>>>>> > (though with some additional flexibility). It can't appear on the >>>>>>> > right side of a `:`, any more than AnyIterator could. >>>>>>> >>>>>>> After this proposal you should be able to use these existentials >>>>>>> anywhere you can place a constraint, so it would work. You can do this >>>>>>> with the protocol composition operator today and the future existential >>>>>>> is just an extension of that capability. >>>>>>> >>>>>>> > >>>>>>> > What *would* work is allowing `where` clauses on associated types: >>>>>>> > >>>>>>> >> protocol Sequence { >>>>>>> >> associatedtype Element >>>>>>> >> associatedtype Iterator: IteratorProtocol where >>>>>>> >> Iterator.Element==Element >>>>>>> >> associatedtype SubSequence: Sequence where SubSequence.Element == >>>>>>> >> Element >>>>>>> >> … >>>>>>> >> } >>>>>>> > >>>>>>> > I believe this is part of the generics manifesto. >>>>>>> > >>>>>>> > -- >>>>>>> > Brent Royal-Gordon >>>>>>> > Architechies >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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] <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
