The or operator for types is rejected in Swift, and probably won’t ever make it, however there might be hope for enums to solve this issue. Some people pointed out in different threads how enums could mimic such behavior.
+1 for != type operator I bumped myself once or twice into such a scenario, but I cannot remember what the use case was back then. -- Adrian Zubarev Sent with Airmail Am 28. Februar 2017 um 08:22:07, Nicolas Fezans via swift-evolution (swift-evolution@swift.org) schrieb: +1 I would also welcome to be able to use "or" and "and" logical operators (not only the not operator) on these constraints. 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. Nicolas On Tue, Feb 28, 2017 at 7:53 AM, Nicholas Maccharoli via swift-evolution <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote: Sent from my iPhone > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution > <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
