I also thought about the Either type.
enum Either<A, B> where A != B {
case -> A
case -> B
}
--
Adrian Zubarev
Sent with Airmail
Am 28. Februar 2017 um 18:35:45, Matthew Johnson via swift-evolution
([email protected]) schrieb:
On Feb 28, 2017, at 11:33 AM, Joe Groff <[email protected]> wrote:
On Feb 28, 2017, at 9:23 AM, Matthew Johnson <[email protected]> wrote:
On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution
<[email protected]> wrote:
On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution
<[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?
Do you have a concrete example where you need this? It'd be good to know
whether the types are ambiguous due to type checker bugs, or whether there's a
principle by which they could be naturally ordered. Instead of overloading, can
you do the type test via `if !(x is CertainType)` within a single
implementation?
The best use case I can think of is if we had enum cases where the associated
value is a subtype of the enum:
enum Result<T, E> where E: Error, T != E {
case some(T) -> T
case error(E) -> E
}
I don't think that's a good design for that type. I can see the desire for a
subtype relationship between T and Result<T, E>, but no good reason for the
error to also be a subtype. That != constraint would have to be propagated
through anything using `Result<T, E>` as well.
Ok, just change it to a fully generic Either type then. I’m not arguing for or
against this constraint, just pointing out a use case that is enabled by it.
It’s reasonable to argue that we don’t want to support this use case.
-Joe
_______________________________________________
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
