[swift-evolution] 'T =?utf-8?Q?=21=3D_?=Type' in where clause

[Adrian Zubarev]

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 (swift-evolution at swift.org) schrieb:


On Feb 28, 2017, at 11:33 AM, Joe Groff <jgroff at apple.com> wrote:


On Feb 28, 2017, at 9:23 AM, Matthew Johnson <matthew at anandabits.com> wrote:


On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:


On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution <swift-evolution at 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?

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
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170228/9f82d0a2/attachment.html>