> 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
