<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 Dec 3, 2015, at 2:12 PM, Tal Atlas <<a href="mailto:me@tal.by" class="">me@tal.by</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">With the awesome expansion of protocol oriented programming that swift has allowed, the lack of generic protocols has felt noticeably lacking and painful in some cases. I made an in depth proposal here: <a href="https://github.com/tal/swift-evolution/blob/tal/generic-protocol-proposal/proposals/NNNN-add-generic-protocols.md" rel="noreferrer" target="_blank" style="color:rgb(42,128,185);text-decoration:none;font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px" class="">https://github.com/tal/swift-evolution/blob/tal/generic-protocol-proposal/proposals/NNNN-add-generic-protocols.md</a><div class=""><br class=""></div><div class="">But the tl;dr is this:</div><div class=""><br class=""></div><div class=""><div class="">protocol Validator<TypeToValidate> {</div><div class=""> var value: TypeToValidate { get set }</div><div class=""> var valueIfValid: TypeToValidate? { get }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct FooStringValidator: Validator<String> {</div><div class=""> //... implementation</div><div class="">}</div><div class=""><br class=""></div><div class="">let stringValidator: Validator<String></div></div></div></div></blockquote><br class=""></div><div>The lack of protocol type erasure when associated types are involved is definitely a big problem, and one we'd like to address. However, I don't think moving wholesale to modeling associated types this way is feasible. Many of the standard library protocols have a lot of associated types. 'CollectionType' for instance has its 'Index' type while also inheriting a 'Generator' from SequenceType, and neither of these is what you typically want to parameterize a collection on—you'd want 'CollectionType<Int>' ideally to refer to a collection whose *Element* is Int without having to fully specify the generator and index if you don't care about them. Swift's protocols also support type system features that make some erased protocol types not actual models of their own protocols; `Equatable` is notorious for this, since a type being `Equatable` to its own values does not mean it can be equated to arbitrary other types; `1 == "1"` is nonsense for instance. We have a number of issues that need to be considered here; don't worry, we are considering them!</div><div><br class=""></div><div>-Joe</div></body></html>