<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 28 Feb 2017, at 22:39, Douglas Gregor 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=utf-8" 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 Feb 27, 2017, at 11:21 PM, Nicolas Fezans 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="">+1<div class="">I would also welcome to be able to use "or" and "and" logical operators (not only the not operator) on these constraints.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You already have “and’ constraints: it’s what you get out of the comma-separated list of constraints in a where clause, or the “&” composition syntax.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I have sometimes generic functions whose code is identical but is written twice: first with 'where T=P1' and then with 'where T=P2', being able to write for instance 'where T=(P1 or P2)' would be very handy IMO.</div><div class="">One could often argue that additional protocols and extensions could be defined as a workaround to the situation I just mentioned but it seems often a bit of an overkill to me when you only have a couple of functions with that combination of requirements.</div></div></div></blockquote><div class=""><br class=""></div><div class="">“Or” constraints are a nonstarter for me, because you can’t meaningfully type-check a generic function that uses “or” constraints: the problem goes exponential in the number of “or” constraints and the meaning of the function can change considerably depending on which set of terms are satisfied—in which case you have ambiguities again!</div><div class=""><br class=""></div><div class="">Whenever this topic comes up, I like to point people at:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2161.pdf" class="">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2161.pdf</a></div></div></div></div></blockquote><div><br class=""></div><div>Should we also follow Recommendation #2 and revert the <b class="">P1 & P2</b> change to return to <b class="">Any<P1, P2></b> :) Half-joking.</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=""><div class="">The problems for Swift won’t be quite as extreme as they would have been for C++0x concepts—the *parsing* won’t have a totally different meaning—but all of the inferred types, selected overloads, etc. could all be completely different.</div><div class=""><br class=""></div><div class="">Note that the paper above talks about “not” constraints as well, and concludes that, effectively “they’re harmless and occasionally useful”, which I think also holds for Swift. However, I *personally* don’t believe that the problems they solve are significant enough to warrant inclusion in Swift 4, which already includes a pile of generics improvements. I suspect that the rest of the core team would agree with that assessment, but of course they’re free to weigh in themselves.</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Nicolas</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 28, 2017 at 7:53 AM, Nicholas Maccharoli via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><div class="gmail_default" style="font-size:12.8px">+ 1 </div><div class="gmail_default" style="font-size:12.8px"><span style="font-size:12.8px" class=""> I personally find this frustrating, but at the same time Im curious as to what the argument against </span><br class=""></div><div class="gmail_default" style="font-size:12.8px">introducing this is. </div><div class="gmail_default" style="font-size:12.8px"><br class=""></div><div class="gmail_default" style="font-size:12.8px">- Nick </div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 28, 2017 at 3:21 PM, David Sweeris via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
<br class="">
<br class="">
Sent from my iPhone<br class="">
<span class="">> On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> I often find myself running into situations where I'll receive "Ambiguous use of..." for overloaded functions or operators. In every case these situations would be easily solved if I could specify "Generic != CertainType" in the where clause of one of the overloads so I can disambiguate the cases. Could this be added to language?<br class="">
<br class="">
</span>+ all the 1s, along with something like "where !(T: Foo)"<br class="">
<br class="">
IIRC, the topic has come up before, though I couldn't (quickly) find it and don't recall what the response was (other than some variation of "no", since we don't have it).<br class="">
<br class="">
- Dave Sweeris<br class="">
<div class="m_4344788437015756409HOEnZb"><div class="m_4344788437015756409h5"><br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br 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>