<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=""><div class="">Hi Karl,</div><div class=""><br class=""></div><div class="">As author of this proposal, the one about constraints on associated types, and the one on type-aliases in protocols (all from the Generics Manifesto - original authorship to Douglas Gregor) I’d like to provide additional reasoning behind my wish to push this proposal through, as a whole.</div><div class=""><br class=""></div><div class="">First of all, there is a personal preference. I’ve used C# for many many years, which has its where clause at the end of the declaration (like this proposal), and I’ve used Swift since its unveiling. The experience with using both styles for several years makes me favour this proposal’s syntax because I find it much easier to read and format for readability.</div><div class=""><br class=""></div><div class="">Constraints on associated type will provide more expressivity but I doubt it will greatly reduce protocol constraint clauses in a majority of cases. And yes, type-aliases in protocols will shorten clauses, but I still think they will more readable with the where clause at the end.</div><div class=""><br class=""></div><div class="">For example, here is a method I took (as-is) from the Standard Library which has a few constraints, and which I further simplified if we imagine that Sequence has an Element typealias for Iterator.Element:</div><div class=""><br class=""></div><div class=""><br class=""><font face="Menlo" style="font-size: 12px;" class="">internal func _arrayOutOfPlaceReplace<<br class=""> B : _ArrayBufferProtocol, C : Collection<br class=""> where<br class=""> C.Element == B.Element,<br class=""> B.Index == Int<br class="">>(<br class=""> _ source: inout B, _ bounds: Range<Int>, _ newValues: C, _ insertCount: Int<br class="">) {</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">See how the Standard Library authors formatted it for readability and how as a consequence arguments which use the generic types are further apart from the declaration of those generic types. But with this proposal, the declaration might be formatted to:</div><div class=""><font face="Menlo" class=""><br class=""><span style="font-size: 12px;" class="">internal func _arrayOutOfPlaceReplace<B, C></span></font><span style="font-size: 12px;" class=""><font face="Menlo" class="">(_ source: inout B, _ bounds: Range<Int>, _ newValues: C, _ insertCount: Int) where<br class=""> B : _ArrayBufferProtocol,</font></span></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> C : Collection,<br class=""> C.Iterator.Element == B.Element,<br class=""> B.Index == Int<br class="">{</font></div><div class=""><br class=""></div><div class="">Do you need believe this is now more readable?</div><div class=""><br class=""></div><div class="">David.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 15 May 2016, at 02:26, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">There is a lot not to like about the idea; even if it was optional. Personally, I feel the problem is solved in a much, much more elegant manner by other proposals.</div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Firstly, the stuff after the ‘where’ clause is getting shorter once typealiases come to protocols. C.Iterator.Element become C.Element. In this one example, that’s 18 characters down to 9 - a 50% reduction in length. We tend to use quite expressive names for associated types, so I expect we’ll see similar gains elsewhere from this very simple proposal.</div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Not only that, but there’s a very good proposal to add ‘where’ clauses to associated types in the protocols themselves, which will likely further reduce the verbosity of the constraints you need to specify at each declaration site. <a href="https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/XXXX-associated-types-constraints.md" class="">https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/XXXX-associated-types-constraints.md</a></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">And then we have generic typealiases and generalised existentials, which would allow us to wrap those ‘where’ clauses in to something much more intelligible to a human being at first glance. ‘StringCollection’ or ‘CollectionOfStrings’ is much clearer than <C:Collection where C.Element==String>, no matter how you chop it up.</div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">If I look at the other proposals, and where we are headed with much more expressive typealiases and associated types, I just feel that that’s the future: that’s the “swift’ way. It’s like type inference - all of the strict constraints are still there under-the-hood, but you’re able to work at a much clearer and more obvious abstraction level. This proposal pulls us further away from things like ‘obviousness’, and like I said, simply feels like an inelegant solution.</div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">At the very least, I think we should shelve the discussion until the larger expansion of typealiases, etc is complete. We should re-evaluate at that time, with a bigger set of more general-purpose tools to produce readable code.</div></div></blockquote></div><br class=""></body></html>