<div dir="ltr">(inline)<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 12:22 PM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.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">Hi Austin,<div><br></div><div>I never had te occasion to say thanks for the work you have put in this proposal, so thanks! I’m really looking forward to be able to have some form of it accepted and implemented in Swift.</div></div></blockquote><div><br></div><div>Thank you! I just hope a proposal like this one ends up being good enough that it means less work for the core team, not more...</div><div> </div><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><br></div><div>Here are a few comments:</div><div><br></div><div>1) Why would <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">Any<></span> and <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">Any<NSView></span> be illegal? What error messages would they generate? Why not make them simply synonymous to <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">Any</span>, and <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">NSView</span>, the same way <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">protocol<></span> currently behaves?</div></div></blockquote><div><br></div><div>"Any<>" being illegal is a syntactic battle that is being fought over in a different thread; I'm not personally invested one way or another. (We might not even adopt "Any" syntax specifically; Joe Groff has ideas for a different syntax that doesn't use the brackets.)</div><div><br></div><div>"Any<NSView>" is an existential, and "NSView" isn't. Existentials' metatypes are different from the metatypes of concrete types, and the ways they can be used with generics is different as well. My opinion is that Any<...> signifies an existential, and allowing the use of "Any<SomeClass>" as a concrete type would just confuse people even more.</div><div> </div><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><br></div><div>2) You say that "An <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">Any<...></span> existential can have zero or one where clauses, <b>following the list of requirements.</b>” This seems to be contradicted in two places: </div></div></blockquote><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><br></div><div>In the example under <b>Nested <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">Any<...></span></b>, which should probably be edited to:</div><div><br></div><div><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;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;color:rgb(51,51,51)"><span style="color:rgb(150,152,150)">// NOT ALLOWED</span>
<span style="color:rgb(150,152,150)">// This is impossible to fufill. A collection's elements cannot be both strings</span>
<span style="color:rgb(150,152,150)">// and integers at the same time.</span>
<span style="color:rgb(167,29,93)">let</span> a <span style="color:rgb(167,29,93)">:</span> <span style="color:rgb(0,134,179)">Any</span><span style="color:rgb(167,29,93)"><</span>Collection, <span style="color:rgb(0,134,179)">Any</span><span style="color:rgb(167,29,93)"><</span>Collection <span style="color:rgb(167,29,93)">where</span> Collection<span style="color:rgb(167,29,93)">.</span>Element <span style="color:rgb(167,29,93)">==</span> <span style="color:rgb(0,134,179)">Int</span><span style="color:rgb(167,29,93)">> </span><span style="color:rgb(167,29,93)">where</span> Collection<span style="color:rgb(167,29,93)">.</span>Element <span style="color:rgb(167,29,93)">==</span> <span style="color:rgb(0,134,179)">String</span><span style="color:rgb(167,29,93)">></span></pre><div><br></div></div></div></blockquote><div><br></div><div>Yes, my wording should have been clearer. What I meant is that you can't have more than one where clause in the *current* Any<>, but you can nest another Any<> that has its own where clause. I'll edit the copy.</div><div> </div><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><div></div></div><div>In the <b><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;background-color:rgba(0,0,0,0.0392157)">where</span> clause</b> section, you say:</div><div><br></div><div><span style="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)">Associated types used within the </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)">where</code><span style="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)"> clause must belong to the protocols in the current or previous requirements.</span></div><div><br></div><div>This sounds a bit bizarre because where clauses always appear at the end, so there is no such “current” requirements and all requirements are “previous”.</div></div></blockquote><div><br></div><div>You are right; I'll fix that. The weird verbiage is a remnant of an earlier draft where each protocol could have its own where clause.</div><div> </div><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><br></div><div>I still have to take the time to finish digesting the end of the proposal.</div></div></blockquote><div><br></div><div>Happy to clarify or answer any questions you might have.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div><br></div><div>David.</div></font></span><div><br><div><blockquote type="cite"><span class=""><div>On 26 May 2016, at 07:53, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></span><div><div dir="ltr"><span class="">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></span><div><div class="h5"><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><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>> _______________________________________________<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></blockquote></div><br></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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div>