> On 28 Feb 2017, at 22:39, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> +1 >> I would also welcome to be able to use "or" and "and" logical operators (not >> only the not operator) on these constraints. > > 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. > >> 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. >> 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. > > “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! > > Whenever this topic comes up, I like to point people at: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2161.pdf > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2161.pdf> Should we also follow Recommendation #2 and revert the P1 & P2 change to return to Any<P1, P2> :) Half-joking.
> 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. > > 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. > > - Doug > >> >> Nicolas >> >> On Tue, Feb 28, 2017 at 7:53 AM, Nicholas Maccharoli via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> + 1 >> I personally find this frustrating, but at the same time Im curious as to >> what the argument against >> introducing this is. >> >> - Nick >> >> On Tue, Feb 28, 2017 at 3:21 PM, David Sweeris via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> Sent from my iPhone >> > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > 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? >> >> + all the 1s, along with something like "where !(T: Foo)" >> >> 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). >> >> - Dave Sweeris >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
