> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution
> <[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
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]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
