<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">* What is your evaluation of the proposal?</div><div class="gmail_extra"><br></div><div class="gmail_extra">+1. I very much want to see this in Swift, and it seems like a logical progression that has the potential to eliminate ugly workarounds.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Is the problem being addressed significant enough to warrant a change to Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yes. Right now the desired relationships between the associated types of a protocol must be written out at each site of use (for example, a generic function declaration that involves that protocol type). When defining a type that conforms to such a protocol these relationships must either be discovered through documentation, or by examining the APIs with which the conforming type will be used.</div><div class="gmail_extra"><br></div><div class="gmail_extra">By changing this implicit contract (through documentation + use site constraints) into an explicit contract (through constraints directly expressed at the point where the associated types are defined), programmers seeking to write conforming types have an easier time understanding how the protocols they are conforming to are intended to work, and programmers seeking to write APIs involving those protocols don&#39;t need to spell out the constraints repeatedly.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Does this proposal fit well with the feel and direction of Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yes. We already have a pretty regular regime for the use of `where` to define constraints, for example in generic type and function declarations and when defining constrained extensions. Adding support for `where` to associated types would be a natural extension of the existing ability to specify protocol conformance, and its semantics would not be surprising to those familiar with the other uses of `where`. (This comment I think applies to all three of the proposed syntaxes.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div class="gmail_extra"><br></div><div class="gmail_extra">n/a</div><div class="gmail_extra"><br></div><div class="gmail_extra">* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Read the review, followed most of the pertinent threads over the past few months with varying degrees of attentiveness.</div></div></div>