<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 13, 2015, at 9:56 PM, Dave Abrahams 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 3:55 PM, Marc Knaup 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 dir="ltr" class="">Hey guys,<div class=""><br class=""></div><div class="">I'm looking at Swift 3.0's goal to improve generics.</div><div class=""><br class=""></div><div class="">Is there any info yet if and how we will be able to refer to instances of protocols that have associated types?</div></div></div></blockquote><div class=""><br class=""></div>As far as I know, this isn't a solvable problem.</div></div></div></blockquote><div><br class=""></div><div>There are solutions to common patterns that we can and should support. If there are only associated types, then the dynamic type 'protocol<Fooable where Foo == SomeSpecificType> is often useful; the standard library itself fakes dynamic type containers for SequenceType and GeneratorType that do this.</div><div><br class=""></div><div>For protocols like Equatable and Hashable with Self parameter requirements, it's true that the compiler can't implicitly produce an Equatable dynamic type that conforms to Equatable. There are a couple possible solutions to this. There's a fairly obvious generalized implementation that could be provided manually:</div><div><br class=""></div><div>extension Equatable: Equatable {}</div><div>func ==(x: Equatable, y: Equatable) -> Bool {</div><div> // If the values are the same type, use that type's == operator.</div><div> // Pretend that 'as? dynamicType' works</div><div> if let yAsX = y as? x.dynamicType {</div><div> return x == yAsX</div><div> }</div><div> // Values of different type aren't ==.</div><div> return false</div><div>}</div><div><br class=""></div><div>We'd want to tweak the language rules for implicit promotion so that things like `1 == 1.0` don't implicitly choose the heterogeneous Equatable implementation of `==`, but this would otherwise allow for protocols to require Equatable and Hashable without forgoing the ability to be useful dynamic types.</div><div><br class=""></div><div>Another possibility is to generalize Equatable so that a conforming type or refining protocol can control how dynamic its equatability is:</div><div><br class=""></div><div>protocol Equatable {</div><div> // The upper bound of type that this type can be equated with. Defaults to `Self`.</div><div> typealias EquatesWith = Self</div><div><br class=""></div><div> // `EquatesWith` must be `Self` or a supertype of `Self`.</div><div> where Self: EquatesWith</div><div><br class=""></div><div> func ==(_: EquatesWith, _: EquatesWith) -> Bool</div><div>}</div><div><br class=""></div><div>A dynamic protocol can then refine Equatable or Hashable by equating with its own dynamic type, rather than defaulting to strict equatability:</div><div><br class=""></div><div>protocol Drawable: Hashable {</div><div> // All Drawables must be equatable with all other Drawables.</div><div> where EquatesWith == Drawable</div><div><br class=""></div><div> func draw()</div><div>}</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">What is the difficulty in supporting this?</div></div></div></blockquote><br class=""></div><div class="">Here's a simple example:</div><div class=""><br class=""></div><div class="">protocol P {</div><div class=""> typealias A</div><div class=""> var x: A { get set }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct Y : P {</div><div class=""> var x: Int</div><div class="">}</div><div class=""><br class=""></div><div class="">struct Z : P {</div><div class=""> var x: String</div><div class="">}</div><div class=""><br class=""></div><div class="">func f(p1: P, p2: P) {</div><div class=""> p1.x = p2.x // assigning an Int to a String?</div><div class="">}</div><div class=""> </div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Simple examples:</div><div class=""><font face="monospace, monospace" class="">var list = [Hashable]()</font></div><div class=""><font face="monospace, monospace" class="">var hashable: Hashable = 2</font></div><div class=""><br class=""></div><div class="">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></div></blockquote></div><div class=""><br class=""></div><div class="">In this case it's "self requirements" inherited from Equatable that make instances of Hashable impossible.</div><div class="">That said, providing for sets/dictionaries of heterogeneous values is a problem we're interested in solving in the standard library.</div><br class=""><div class="">
-Dave<div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RoDF4MveSEMYBIqIJA6ub1g8cOZ-2BVYvqV-2FqygPhjPn8Tg8CKwe5XHANE6Ze7XQOQ2ID-2BjIge4qex3yfeScaRPGNPC5MkTL8jx0CZVfn5-2BBgz8ayDdxmZEWh7n17YKSHY-2FplJ5OBTILpAj8Fpr5rd8tWlhqAsHnoJElBVSGSIe0VCIfi4ZgTzANLQtksyVPB7FsbFqltdQ-2F-2F61saV0-2B31Lwy7hCbEsy5oP2Pw9N2JSUs-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;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>