<div dir="ltr">Two more minor things:<div><br></div><div>- The wording of that section should be amended to make it clear that the current behavior (existentials with exactly one requirement and no constraints are allowed to satisfy totally unconstrained generic type parameters) continues to be allowed.</div><div><br></div><div>- Unfortunately, even if we did somehow support this feature your snippet would be impossible to express :(. Set<Any<A, B>> requires Any<A, B> to conform to Hashable, but protocols conforming to other protocols is marked as a non-started in the Completing Generics document.</div><div><br></div><div>Hope that helps,</div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 28, 2016 at 12:38 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There are a couple of reasons why it's not possible.<div><br></div><div>- You can't force A and B to be protocols (forcing them to be protocols is distinct from forcing them to be types that implement a certain protocol). If you pass in two concrete types "Any<A, B>" becomes invalid.</div><div><br></div><div>- If a generic type has any constraints on it, that generic type cannot be fulfilled by an existential today. A protocol is not considered to implement itself.</div><div><br></div><div>Changing how generics work to accommodate this functionality is beyond the scope of this proposal, which is already too big as is.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Austin</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 28, 2016 at 12:31 PM, Thorsten Seitz <span dir="ltr"><<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I’m not happy with that restriction in the proposal:</div><div><br></div><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)">Existentials cannot be used with generics in the following ways:</p><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><li><p style="margin-top:16px;margin-bottom:16px">In generic declarations, with the requirements composed out of generic type variables:</p><div style="margin-bottom:16px"><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal"><span style="color:rgb(150,152,150)">// NOT ALLOWED</span>
<span style="color:rgb(167,29,93)">func</span> <span style="color:rgb(121,93,163)">foo</span><A, B>(x: A, y: B) <span style="color:rgb(167,29,93)">-></span> <span style="color:rgb(0,134,179)">Any</span><A, B> { <span style="color:rgb(167,29,93)">...</span> }</pre></div></li></ul><div><br></div><div>Why is that not allowed?</div><div><br></div><div>I would have hoped to be able to write something like</div><div><br></div><div>func union<A, B>(x: Set<A>, y: Set<B>) -> Set<Any<A, B>> { … }</div><span><font color="#888888"><div><br></div><div><br></div><div>-Thorsten</div><div><br></div><div><br></div><div><br></div></font></span><div><blockquote type="cite"><div><div><div>Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:</div><br></div></div><div><div><div><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As always, the link is here, and feedback would be greatly appreciated: <a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md" target="_blank">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md</a></div><div><br></div><div>Best,</div><div>Austin</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
<br>
Sent from my iPad<br>
<span><br>
On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> 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.<br>
>><br>
>> protocol Sequence {<br>
>> associatedtype Element<br>
>> associatedtype Iterator: any<IteratorProtocol where IteratorProtocol.Element==Element><br>
>> associatedtype SubSequence: any<Sequence where Sequence.Element == Element><br>
>> …<br>
>> }<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span><br>
><br>
> What *would* work is allowing `where` clauses on associated types:<br>
><br>
>> protocol Sequence {<br>
>> associatedtype Element<br>
>> associatedtype Iterator: IteratorProtocol where Iterator.Element==Element<br>
>> associatedtype SubSequence: Sequence where SubSequence.Element == Element<br>
>> …<br>
>> }<br>
><br>
> I believe this is part of the generics manifesto.<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
</span></div></div><span><div><div>> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></span></blockquote></div><br></div><span>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>