Interesting comment about worries that you&#39;d be dispatched to the least good SS version . A different language with different constraints, but when LINQ to Objects implementers needed to provide optimized c# implementations for some operations they chose a runtime type check to dispatch to the optimized version. For example, while API is exposed as IEnumerable&lt;T&gt; there are method implementations that check for ICollection&lt;T&gt; at runtime in order to hit more efficient implementations. So static dispatch is good, but win for collections often big enough to overcome a hit from <span></span>dynamic dispatch. <br><br>On Sunday, October 2, 2016, plx via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 30, 2016, at 1:23 PM, Douglas Gregor &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dgregor@apple.com&#39;);" target="_blank">dgregor@apple.com</a>&gt; wrote:</div><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><br></div></blockquote><blockquote type="cite"><div style="word-wrap:break-word"><div>This is purely anecdotal but I had a lot of utility code laying around that I’d marked with notes like `// TODO: revisit once conditional conformances are available`.</div><div><br></div><div>When I was leaving those notes I was expecting to need overlapping conformances often, but I reviewed them *before* replying and I actually haven’t found an example where having overlapping conformances is both (1) a significant win and also (2) a win in a way that’d be of broad, general interest.</div><div><br></div><div>- 80% have no real need for overlapping conditional conformances</div><div>- 15% might have “elegance gains” but nothing practically-significant</div><div>- 5% would *probably* see real gains but are likely not of broad interest</div><div><br></div><div>…which wasn’t what I was expecting, but leaves me a lot more comfortable without overlapping conformances for now than I was in the abstract.</div></div></blockquote><div><br></div><div>Very interesting, thanks for doing this review!</div></div></div></blockquote><div><br></div><div>I&#39;ve taken the time to provide a bit more color on the 80/15/5 breakdown because I don&#39;t see much discussion for this proposal in terms of concrete situations...just theoretical concerns and theoretical possibilities. I don&#39;t have any completed code either, but I have notes and to-do lists for things I was planning to do, and I think seeing even some semi-concrete scenarios might be helpful here.</div><div><br></div><div>The &quot;80%&quot; are generally analogous to the `SomeWrapper` in the writeup; as a concrete example, I was waiting on the availability of conditional conformances to resume work on an emulation of structural unions, e.g. something like:</div><div><br></div><div>  enum Sum2&lt;A,B&gt; {</div><div>    case a(A)</div><div>    case b(B)</div><div>  }</div><div>  </div><div>...(and analogously for 3, 4, as-necessary). </div><div><br></div><div>There&#39;s a very obvious way to write `extension Sum2 : Equatable where A:Equatable, B:Equatable {}`...and at the time I set this aside, I was expecting to also want to come back and have additional conformances for things like `...where A:Equatable, B:AnyObject` (using `===` for comparing `B`) and so on for other combinations.</div><div><br></div><div>Upon revisiting such things in light of the proposal, I now think differently: for this case it seems like a better long-term approach anyways to stick to a single conformance and work with it like this:</div><div><br></div><div>  extension Sum2:Equatable where A:Equatable, B:Equatable {</div><div>    // details elided</div><div>  }</div><div>  </div><div>  /// Adaptor using `ObjectIdentifier` to implement `==`.</div><div>  struct ObjectWrapper&lt;Wrapped:<wbr>AnyObject&gt; : Equatable, Hashable {</div><div>    let wrapped: Wrapped</div><div>  }</div><div>  </div><div>...as upon reflection I really would prefer dealing with the hassle of working with `Sum2&lt;A,ObjectWrapper&lt;B&gt;&gt;` in situations where -- in theory -- `Sum2&lt;A,B&gt;` could do -- to the hassle of writing out 4+ conformances for `Sum2` (and so on...even with nice code-gen tools that&#39;s going to be a lot of bloat!). </div><div><br></div><div>What changed my mind was tracing through the implications of conditional conformances for the use-site ergonomics of adaptors like `ObjectWrapper` above; what I mean is, suppose I have a protocol like this:</div><div><br></div><div>  protocol WidgetFactory {</div><div>    associatedtype Widget</div><div>    associatedtype Material</div><div>    </div><div>    func produceWidget(using material: Material) -&gt; Widget</div><div>  }</div><div><br></div><div>...then it&#39;s rather easy to simply write this type of boilerplate:</div><div><br></div><div>  extension ObjectWrapper: WidgetFactory where Wrapped: WidgetFactory {</div><div>    typealias Widget = Wrapper.Widget</div><div>    typealias Material = Wrapper.Material</div><div>    </div><div>    func produceWidget(using material: Material) -&gt; Widget {</div><div>      return base.produceWidget(using: material)</div><div>    }</div><div>  }</div><div>  </div><div>...which thus means I have the tools I need to make my use of wrappers like the `ObjectWrapper` largely transparent at the use sites I care about; e.g. I can write a single conditional conformance like this:</div><div><br></div><div>  extension Sum2: WidgetFactory </div><div>    where </div><div>    A:WidgetFactory, B:WidgetFactory,</div><div>    A.Material == B.Material,</div><div>    A.Widget == B.Widget {</div><div>    </div><div>    typealias Widget = A.Widget</div><div>    typealias Material = A.Material</div><div>    </div><div>    func produceWidget(using material: Material) throws -&gt; Widget {</div><div>      switch self {</div><div>        case let .a(aa): return aa.produceWidget(using: material)</div><div>        case let .b(bb): return bb.produceWidget(using: material)</div><div>      }</div><div>    }</div><div>    </div><div>  }</div><div>  </div><div>...and it will apply even in situations where circumstances left me using `ObjectWrapper` (or similar) on any of the type parameters to `Sum2` (e.g. if I also needed an `Equatable` conformance for whatever reason).</div><div><br></div><div>At least for now--when I&#39;m still just revisiting plans and thinking about it in light of the proposal--I really would prefer having a simpler language and writing this type of boilerplate, than having a more-complex language and writing the *other* type of boilerplate (e.g. the 4+ `Equatable` conformances here, and so on for other situations).</div><div><br></div><div>Note that I&#39;m not claiming the above is the only use for overlapping conditional conformances -- not at all! -- just that situations like the above comprise about 80% of the things I was intending to do with conditional conformances...and that after revisiting them expecting to be troubled by the proposed banning of overlapping conformances, I&#39;m now thinking I&#39;d wind up not using the overlapping-conformance approach in such cases even if it were available.</div><div><br></div><div>So that&#39;s the first 80%.</div><div><br></div><div>Moving on, the next 15% are places where there&#39;s some forced theoretical or aesthetic inelegance due to the lack of overlapping conformances, but none of these seem to have any significant practical import.</div><div><br></div><div>A representative case here is that I currently have the following pair:</div><div><br></div><div>  /// `ChainSequence2(a,b)` enumerates the elements of `a` then `b`.</div><div>  struct ChainSequence2&lt;A:Sequence,B:<wbr>Sequence&gt; : Sequence</div><div>    where A.Iterator.Element == B.Iterator.Element  {</div><div>    // elided</div><div>  }</div><div><br></div><div>  /// `ChainCollection2(a,b)` enumerates the elements of `a` then `b`.</div><div>  struct ChainCollection2&lt;A:Collection,<wbr>B:Collection&gt; : Collection</div><div>    where A.Iterator.Element == B.Iterator.Element {</div><div>    // ^ `where` is not quite right, see below</div><div>  }</div><div><br></div><div>...and obviously conditional conformances will allow these to be consolidated into a single `Chain2` type that then has appropriate conditional conformances (and for which the cost/benefit for me will tip in favor of adding conditional conformances to `BidirectionalCollection` and `RandomAccessCollection`, also).</div><div><br></div><div>On paper--e.g., theoretically--the lack of overlapping conformances leaves in a few aesthetic issues...for example, at present `ChainCollection2` actually has to be one of these:</div><div><br></div><div>  // &quot;narrower&quot; option: not all `A`, `B` can necessarily be used together:</div><div>  struct ChainCollection2&lt;A:Collection,<wbr>B:Collection&gt; : Collection</div><div>    where </div><div>    A.Iterator.Element == B.Iterator.Element,</div><div>    A.IndexDistance == B.IndexDistance {</div><div>    typealias IndexDistance = A.IndexDistance</div><div>  }</div><div><br></div><div>  // &quot;wasteful&quot; option: theoretically in some cases we are &quot;overpaying&quot; and </div><div>  // using a stronger `IndexDistance`, but now we can use any `A` and `B`</div><div>  struct ChainCollection2&lt;A:Collection,<wbr>B:Collection&gt; : Collection</div><div>    where A.Iterator.Element == B.Iterator.Element {</div><div>    typealias IndexDistance = IntMax</div><div>  }</div><div><br></div><div>With overlapping conditional conformances you could have both: one conformance that uses base collections&#39; `IndexDistance` when possible, and another that uses `IntMax` when necessary...but without conditional conformances it&#39;s necessary to choose between the &quot;narrower&quot; approach or the &quot;wasteful&quot; approach (preserving the status quo).</div><div><br></div><div>If you&#39;re following along I&#39;m sure you&#39;re aware that in this specific case, this &quot;choice&quot; is purely academic (or purely aesthetic)...if you go with the `IntMax` route there&#39;s almost always going to be between &quot;no actual difference&quot; and &quot;no measurable difference&quot;, so even if it *maybe* feels a bit icky the right thing to do is get over it and stop making a mountain out of an anthill.</div><div><br></div><div>Note that I&#39;m well aware that you can choose to see this as a concrete instance of a more-general problem -- that the lack of overlapping conformances would potentially leave a lot of performance on the table due to forcing similar decisions (and in contexts where there *would* be a real difference!) -- but speaking personally I couldn&#39;t find very much in my &quot;chores pending availability of conditional conformance&quot; that both (a) fell into this category and (b) had more than &quot;aesthetic&quot; implications. </div><div><br></div><div>This brings me to that last 5% -- the handful of things for which overlapping conformances have nontrivial benefits -- and my conclusion here is that these tended to be things I doubt are of general interest.</div><div><br></div><div>An example here is that I like to use a function that takes two sequences and enumerates their &quot;cartesian product&quot;, with the following adjustments:</div><div><br></div><div>- no specific enumeration *ordering* is guaranteed</div><div>- does something useful even with infinite, one-shot sequences...</div><div>- ...meaning specifically that it will eventual-visit any specific pair (even when one or both inputs are infinite, one-shot)</div><div><br></div><div>...(useful for doing unit tests, mostly), which to be done &quot;optimally&quot; while also dotting all the is and crossing all the ts would currently require at least 8 concrete types:</div><div><br></div><div>- 4 sequences, like e.g.:</div><div>  - UnorderedProductSS2&lt;A:<wbr>Sequence, B:Sequence&gt;</div><div>  - UnorderedProductSC2&lt;A:<wbr>Sequence, B:Collection&gt;</div><div>  - UnorderedProductCS2&lt;A:<wbr>Collection, B:Sequence&gt;</div><div>  - UnorderedProductCC2&lt;A:<wbr>Collection, B:Collection&gt;</div><div>- 4 iterators (one for each of the above)</div><div><br></div><div>...since you need to use a different iteration strategy for each (yes you don’t *need* 8 types, but I’m trying to “dott all is, cross all ts” here). </div><div><br></div><div>In theory overlapping conditional conformances could be used to cut that down to only 5 types:</div><div><br></div><div>- 1 type like `UnorderedProduct&lt;A:Sequence,<wbr>B:Sequence&gt;`</div><div>- the same 4 iterators from before, each used with the appropriate conformance</div><div><br></div><div>...which *is* less code *and* seemingly provides nontrivial gains (the `SS` variant must maintain buffers of the items it&#39;s already seen from each underlying sequence, but the others have no such requirement).</div><div><br></div><div>But, to be honest, even if those gains are realized, this is the kind of situation I&#39;m perfectly comfortable saying is a &quot;niche&quot; and neither broadly relevant to the majority of Swift developers nor broadly relevant to the majority of Swift code; if overlapping conformances were available I&#39;d use them here, but I&#39;m not going to ask for them just to be able to use them here.</div><div><br></div><div>Also, I&#39;m skeptical these gains would be realized in practice: between the proposed &quot;least specialized conformance wins&quot; rule and Swift&#39;s existing dispatch rules in generic contexts, it seems like even if overlapping conformances *were* allowed and I *did* use them, I&#39;d still wind up getting dispatched to the pessimal `SS` variant in many cases for which I&#39;d have been hoping for one of the more-optimal versions.</div><div><br></div><div>So between the niche-ness of such uses -- and their being 5% or less of what I was hoping to do -- and my skepticism about how dispatch would pan out in practice, I can&#39;t get behind fighting for overlapping conformances at this time unless they&#39;d be permanently banned by banning them now.</div><div><br></div><div>As already stated, I do think that their absence *will* reveal some *true* pain points, but I think it makes sense to adopt a &quot;wait-and-see&quot; approach here as some more-targeted solution could wind up being enough to address the majority of those future pain points.</div><div><br></div><div>These are my more-detailed thoughts after looking at what I was planning to do with conditional conformances once the became available. I realize it doesn&#39;t touch on every conceivable scenario and every conceivable use, but I want to reiterate that I did my review expecting to find a bunch of things that I could use as justifications for why Swift absolutely should have overlapping conditional conformances right now...but on actually looking at my plans, I couldn&#39;t find anything for which I actually felt that way.</div><div><br></div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="white-space:pre-wrap">        </span>- Doug</div></div></blockquote></div><br></div></blockquote>