<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello Tony,<div class=""><br class=""></div><div class="">Sorry, I never took the time to comment. I see the issues you are pointing, but they seem to be more generic than only concerning associated type constraints. For example, the "inheritance from non-protocol, non-class type” error also concerns generic types. Perhaps it should be best to start new discussions and new proposal for those issues? This proposal already seems like a mouthful to me.</div><div class=""><br class=""></div><div class="">David.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 25 Apr 2016, at 18:01, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I really like where this proposal is headed.<div class=""><br class=""></div><div class="">Would this syntax also support constraining associated types based on "inheritability" (for lack of a better word)? For example, a couple times I've hit a situation where I want to express a supertype/subtype relationship. A contrived example:</div><div class=""><br class=""></div><div class="">protocol Foo {</div><div class="">&nbsp; associatedtype Bar</div><div class=""><br class=""></div><div class="">&nbsp; func f&lt;Baz: Bar&gt;(b: Baz.Type) -&gt; Baz</div><div class="">}</div><div class=""><br class=""></div><div class="">This currently gives me the error "inheritance from non-protocol, non-class type 'Self.Bar'." This makes sense in a way, because a type conforming to Foo could define Bar to be anything, including a struct.</div><div class=""><br class=""></div><div class="">I see a few ways to address this:</div><div class=""><br class=""></div><div class=""><span style="line-height:1.5" class="">(1) Allow users to write "associatedtype Bar: class" to indicate that the conforming class must set Bar to be a class type, which would let the type checker know that the Baz: Bar constraint is valid. This gets us partially there, but is still somewhat limiting because other supertype/subtype relationships could not be expressed, such as Bar being an arbitrary protocol and Baz being any type that conforms to that protocol.</span><br class=""></div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">(2) Allow users to write "associatedtype Bar: _____", where _____ is some way of expressing any arbitrary type that is inheritable: this would include classes but also protocols. The difference here is instead of specifying a specific protocol, conforming types could put any protocol here, binding Bar in function f() to that protocol and then Baz would be any type conforming to Bar.</span></div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><div class="">(3) Allow the syntax above unchanged. If a conforming type defines Bar to be a struct, loosen the check and still allow it such that the only possible type that can satisfy Baz is Bar itself. This would be consistent with other generic constraints that are class-based, where a constraint of the form f&lt;SomeClass: BaseClass&gt; can still satisfy SomeClass by using BaseClass itself.</div></div><div class=""><br class=""></div><div class="">While writing this, I noticed some other constructs that seem like they should work, but don't:</div><div class=""><br class=""></div><div class="">protocol SomeProtocol {}</div><div class="">protocol Foo {</div><div class="">&nbsp; associatedtype Bar: SomeProtocol</div><div class="">&nbsp; func f&lt;Baz: Bar&gt;(b: Baz.Type) -&gt; Baz</div><div class="">&nbsp; // ^ inheritance from non-protocol, non-class type 'Self.Bar'</div><div class="">&nbsp; // Shouldn't the compiler know that Bar is constrained by a protocol here?</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class="">class SomeClass {}</div><div class="">protocol Foo {</div><div class="">&nbsp; associatedtype Bar: SomeClass</div><div class="">&nbsp; func f&lt;Baz: Bar&gt;(b: Baz.Type) -&gt; Baz</div><div class="">&nbsp; // ^ inheritance from non-protocol, non-class type 'Self.Bar'</div><div class="">&nbsp; // Same problem as above, essentially.</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><div class="">protocol A {}</div><div class="">protocol B {}</div><div class="">protocol Foo {</div><div class="">&nbsp; associatedtype Bar: protocol&lt;A, B&gt;</div><div class="">&nbsp; // ^ This one doesn't appear to even get past the parser, which is unfortunate.</div><div class="">&nbsp; // To express the notion of an associatedtype conforming to two protocols, you</div><div class="">&nbsp; // have to create a third protocol and extend the type you wish to use to conform</div><div class="">&nbsp; // to that protocol.</div><div class=""><span style="line-height:1.5" class="">}</span><br class=""></div></div><div class=""><br class=""></div><div class="">Some of these issues may have been addressed in "Completing generics", but they seem like they would fit into this proposal as well.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Apr 25, 2016 at 8:30 AM Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><br class=""><br class="">Sent from my iPad</div></div></div><div dir="auto" class=""><div class=""><div class=""><br class="">On Apr 25, 2016, at 9:58 AM, Thorsten Seitz &lt;<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class="">Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">I really like this proposal.&nbsp; It is a nice step forward from current state. &nbsp;</div><div class=""><br class=""></div><div class="">However, it looks like it doesn't allow us to express constraints that elate two or more associated types together, such as requiring both to have the same Element type. </div></div></blockquote><div class=""><br class=""></div><div class="">Did I miss something? I thought that was the exact example given in the motivation section?</div></div></blockquote><div class=""><br class=""></div></div></div><div dir="auto" class=""><div class=""><div class="">You are right.&nbsp; I'm not sure how I missed that.&nbsp; I think it is because the constraints are attached to a single associatedtype declaration rather than being at the top level of the protocol declaration.&nbsp;</div><div class=""><br class=""></div><div class="">It feels slightly awkward to have to attach such constraints to one of the associatedtype declarations as they are effectively peers in the same type constraint.&nbsp; Allowing such constraints to stand alone would look similar to Doug's example in the issues section.&nbsp; I would prefer to look for a syntax for generic constraints on declarations that allows for freestanding and refined constraints in protocols.</div></div></div><div dir="auto" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">-Thorsten&nbsp;</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">&nbsp;I think it would be a good idea to solve the general problem of constraining associated types if possible.&nbsp; The general case is an important part of completing generics IMO so it should be within the scope of Swift 3 to consider it.</div><div class=""><br class=""></div><div class="">Matthew<br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Apr 24, 2016, at 3:34 PM, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">I wrote the proposal which was discussed to introduce generic constraints for associated types. I’d like to get some feedback on it and get it ready before submitting it:<div class=""><br class=""></div><div class=""><h1 style="font-size:2.25em;margin-right:0px;margin-bottom:16px;margin-left:0px;line-height:1.2;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255);margin-top:0px!important" class="">More Powerful Constraints for Associated Types</h1><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)" class=""><li class="">Proposal:&nbsp;<a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">SE-XXXX</a></li><li class="">Author(s):&nbsp;<a href="http://github.com/hartbit" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">David Hart</a></li><li class="">Status:&nbsp;<strong class="">TBD</strong></li><li class="">Review manager: TBD</li></ul><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255)" class=""><a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#introduction" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank" class=""><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Introduction</h2><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)" class="">This proposal seeks to introduce a&nbsp;<code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;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" class="">where</code>&nbsp;expression to associated types declarations to bring the same expressive power as generic type constraints.</p><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)" class=""><em class="">This proposal was discussed on the Swift Evolution list in the&nbsp;<a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/14243" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">[swift-evolution] [Completing Generics] Arbitrary requirements in protocols</a>&nbsp;thread.</em></p><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255)" class=""><a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#motivation" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank" class=""><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Motivation</h2><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)" class="">Currently, associated type declarations can only express simple inheritance constraints and not the more sophisticated constraints available to generic types with the&nbsp;<code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;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" class="">where</code>&nbsp;expression. Some designs, including many in the Standard Library, require more powerful constraints for associated types to be truly elegant. For example, the&nbsp;<code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;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" class="">SequenceType</code>&nbsp;protocol can be declared as follows:</p><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:16px;line-height:1.45;padding:16px;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-wrap:normal;color:rgb(51,51,51)" class=""><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;border:0px;display:inline;line-height:inherit;word-wrap:normal" class="">protocol Sequence {
    associatedtype Iterator : IteratorProtocol
    associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element
    ...
}
</code></pre><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255)" class=""><a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#detail-design" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank" class=""><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Detail Design</h2><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)" class="">With this proposal, the grammar for protocols associated types would be modified to:</p><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)" class=""><em class="">protocol-associated-type-declaration</em>&nbsp;→&nbsp;<em class="">attributes<span style="font-size:12px;line-height:0;vertical-align:baseline" class="">opt</span></em>&nbsp;<em class="">access-level-modifier<span style="font-size:12px;line-height:0;vertical-align:baseline" class="">opt</span></em>&nbsp;<strong class="">associatedtype</strong>&nbsp;<em class="">typealias-name</em>&nbsp;<em class="">­type-inheritance-clause­<span style="font-size:12px;line-height:0;vertical-align:baseline" class="">opt­</span></em>&nbsp;<em class="">typealias-assignment­<span style="font-size:12px;line-height:0;vertical-align:baseline" class="">opt</span></em>&nbsp;<em class="">requirement-clause<span style="font-size:12px;line-height:0;vertical-align:baseline" class="">opt</span></em></p><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)" class="">The new&nbsp;<code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;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" class="">requirement-clause</code>&nbsp;is then used by the compiler to validate the associated types of conforming types.</p><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255)" class=""><a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#issues" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank" class=""><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Issues</h2><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)" class="">Douglas Gregor argues that the proposed syntax is redundant when adding new constraints to an associated type declared in a parent protocol and proposes another syntax:&nbsp;</p><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:16px;line-height:1.45;padding:16px;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-wrap:normal;color:rgb(51,51,51)" class=""><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;border:0px;display:inline;line-height:inherit;word-wrap:normal" class="">protocol Collection : Sequence {
    where SubSequence : Collection

</code></pre><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)" class="">But as Douglas notes himself, that syntax will become ambiguous if we adopt the generic where expression at the end of declarations like discussed in the following thread:&nbsp;<a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058</a>. For those reasons, it might be wiser not to introduce the shorthand syntax.</p><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.225;font-size:1.75em;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);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';background-color:rgb(255,255,255)" class=""><a href="https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#acknowledgements" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank" class=""><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Acknowledgements</h2><div style="margin-top:0px;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);margin-bottom:0px!important" class="">Thanks to Dave Abrahams and Douglas Gregor for taking the time to help me through this proposal.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote></div></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>