<div dir="ltr">@Andrew sure you could provide an init implementation for a protocol. It would be like a factory for that protocol similar to class clusters in Objective-C.<div>Actually a proposal I'm working on depends on that being possible somehow :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 3:02 PM, Andrew Bennett <span dir="ltr"><<a href="mailto:cacoyi@gmail.com" target="_blank">cacoyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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/" target="_blank">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="HOEnZb"><div class="h5"><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><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><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><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" 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>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>