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]>:
>
> 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]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
