[swift-evolution] 'T != Type' in where clause

[Matthew Johnson]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170228/e32f5a3a/attachment.html>