Thanks! And thanks for your great work on this proposal! -Thorsten
> Am 27.05.2016 um 10:10 schrieb Austin Zheng <[email protected]>: > > This is a good point. "a.Element" is not an existential, it is a concrete > type whose value is not known at compile time. So there is nothing in > principle stopping it from being passed into a generic function. This would > also allow you to do thing like e.g. make an Array of a.Elements, which might > be useful. (You can imagine calling an API that returns an "a.Index" several > times, putting the returned values in an array, and then passing an > "[a.Index]" into a different API.) > > I will remove the restriction and make a note; if the proposal goes to review > the impetus will be on the core team to cut it out of they think it is too > difficult to implement. > > Austin > >> On May 26, 2016, at 11:08 PM, Thorsten Seitz <[email protected] >> <mailto:[email protected]>> wrote: >> >> protocol Protocol1 { } >> >> func doSomething<T : Protocol1>(arg: T) { ... } >> >> func doSomethingElse(a: Any<Collection where .Element : Protocol1>) { >> let firstElement : a.Element = a.first! >> >> // NOT ALLOWED - allowing this would mean allowing doSomething<T> to be >> // specialized upon "a.Element", which makes little sense. >> doSomething(firstElement) >> } >> >> I do not agree with this restriction. This should be possible. >> `a.Element` is constrained to `Protocol1` so I don’t see a reason to forbid >> calling doSomething(firstElement) which expects a `Protocol1`. >> >> I do not understand the comment "allowing doSomething<T> to be specialized >> upon ‚a.Element‘“. >> Swift is not C++ where generics are templates which are realized for the >> type parameters involved. In Swift like in most other languages a generic >> function exists only once and will just use the types given within their >> restrictions, i.e. here T must conform to Protocol1, so all methods of >> Protocol1 can be used on `arg` within `doSomething`. The type `a.Element` >> does not exist within `doSomething` and therefore no escaping takes place. >> >> -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] https://lists.swift.org/mailman/listinfo/swift-evolution
