<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 May 2016, at 19:51, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></blockquote><div><br class=""></div><div>I’m a +1, however personally I’d prefer this to be optional my constraints aren’t that complex, for example:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someMethod<T where T.Element == String>(value:T) { … }</font></div><div><br class=""></div><div>Personally I prefer to keep such simple cases as they are, but would happily use the new ability to move more complex ones (e.g- dealing with Generator.Element and multiple constraints) to the end as proposed.</div><div><br class=""></div><div>So I’m +1, but I don’t think it should be one or the other, I’d prefer to have both options, with a recommendation that trailing constraints be used in complex cases for clarity.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></blockquote><div><br class=""></div><div>Generic constraints are one of the most powerful, and daunting, features of Swift, so anything that makes them a bit neater and keeps function signatures tidy is an improvement. Of course there’s a lot more that can be done to simplify generic constraints further, but given the simple elegance of this improvement it easily justifies inclusion.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></blockquote><div><br class=""></div><div>I’d say yes, since the feature itself is unchanged and already part of Swift, it’s just the location that is being moved.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></blockquote><div><br class=""></div><div>Quick read through, which is plenty since the proposal is fairly straightforward, I’ve also been following the discussion for a while.</div></div></body></html>