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 <tseit...@icloud.com> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>
>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>> Sent from my iPad
>>
>> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
