<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It is definitely possible to solve this problem for associated types by binding or constraining them. The ML module system has a feature that is roughly analogous to this. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think Self is quite a bit trickier, although there is effectively a implicit constraint that Self conforms to the protocol in question so it may be possible to make use of that information.<br><br>Sent from my iPad</div><div><br>On Dec 14, 2015, at 8:02 AM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I agree that this is an issue, I'd really like to see a language feature to address it.<div><br></div><div>In some circumstances you can work around the issue with type-erasure. You implement a generic wrapper (like AnySequence) that can take anything conforming to that protocol and expose it with a single concrete interface.</div><div><br></div><div>I learnt a lot implementing a few of these. There's a good article on it here:</div><div><a href="https://realm.io/news/type-erased-wrappers-in-swift/">https://realm.io/news/type-erased-wrappers-in-swift/</a></div><div><br></div><div>I wouldn't be too surprised if Apple formalises type erasure somehow, the implementation is very mechanical and could be automated. For example: If you have a protocol MyProtocol that has type requirements then perhaps MyProtocol.Any would refer to an automatically generated type erased concrete type. I suppose you could also do:</div><div><br></div><div>typealias AB = protocol<A,B></div><div>AB.Any</div><div><br></div><div>The main problem with current implementations seems to be, for example: ZipSequence is a SequenceType, but ZipSequence is not an AnySequence.</div><div><br></div><div>Also you cannot necessarily conform to a protocol if it has things like initialiser requirements.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 12:45 AM, Tal Atlas via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">This is the error that gets in my way the most when trying to do protocol oriented programming. It can be super frustrating. That lead me to make a proposal a few weeks back for having generic protocols.<br><br>In that proposal some swift core people expressed that they were keenly aware of said pain. And while they didn't deliver details in time or implementation they expressed that there were efforts ongoing to solve it. </div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sun, Dec 13, 2015 at 6:55 PM Marc Knaup via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hey guys,<div><br></div><div>I'm looking at Swift 3.0's goal to improve generics.</div><div><br></div><div>Is there any info yet if and how we will be able to refer to instances of protocols that have associated types?</div><div>What is the difficulty in supporting this?</div><div><br></div><div>Simple examples:</div><div><font face="monospace, monospace">var list = [Hashable]()</font></div><div><font face="monospace, monospace">var hashable: Hashable = 2</font></div><div><br></div><div>Right now all we get is</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">protocol 'Hashable' can only be used as a generic constraint because it has Self or associated type requirements</blockquote><div><br></div><div>Thanks,</div><div> Marc</div><div> </div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RVJ3oK8DhV2nk8GArr3gdELPnoZa5KIhM7Fm9-2Bmn1SvtHTnEi8YJSTU-2FnnYo3HOJlVinPxWLQGOafeK4m2K5cjJFKPxvaV-2Bzxa6fvcpYTA1-2FFWt5oBqdfRMARJtZqHNtYFmsenR-2FD6jZTjEKN2PTgxmyP-2FbBcHC8k7-2BaEQMfM-2B3Ksk-2BZ-2BoLSw37oCbE4PdK8DBvYLYSVPcRFTUuyUaCPkA-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<span class=""><br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uRI4Qz1Cd3knZjplMzWPPDr8IqZ-2B1XKQyUcCfnx97ZTq-2ByS9n-2BOPUl-2BYSATphTGM4U-2Fww-2FCfUQQ02vM4nvaGS6rY3h-2FQOO8XqQbCgt-2B9OWuF1lL-2BEQLLmteyIj3EUAEKH2YmiEv0wca9ZNdyqldoYPtm3DB4-2BWDYmeeOzseuI9X8yNWIaTDa0eFC5msn3sGJtw-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAe7QiVDcohu9cjZuosDT1AEslTlxKscSlLPrOsCR7OzDzFAy-2FLzAtkjkvEhOMJfwTTVNBnTLvfmobbKDiAb-2Bx6yBJ55Vj9E8u1JTOjwGqKklM-2BgAcYBuKabGl58HAxhtu2-2BmPmCuyuyoUF2bkhfqobYVP3SulkRoBerwd-2FZ4EIDRbtsUQZds0BAWRor5CzIzjQ-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>