Great! Thanks! -Thorsten
> Am 29.05.2016 um 22:29 schrieb Austin Zheng <[email protected]>: > > 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]>: >>>> >>>> >>>> On May 29, 2016, at 7:04 AM, Matthew Johnson <[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]>: >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> Best, >>>>>>>> Austin >>>>>>>> >>>>>>>>> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution >>>>>>>>> <[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] >>>>>>>>> > 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
