[swift-users] Overload by return type optionality?

[Hooman Mehr]

I know, but a simple 

let x = 2/3

becomes ambiguous which I don’t like.

> On Oct 13, 2016, at 8:00 PM, Mark Lacey <mark.lacey at apple.com> wrote:
> 
> 
>> On Oct 13, 2016, at 5:37 PM, Hooman Mehr via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> 
>>> On Oct 13, 2016, at 3:31 PM, Rick Mann via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> Would it make sense to be able to specify priority for a set of overloaded methods to help resolve ambiguity?
> 
> I don’t think we want to head down that route, partially because using a contextual type as mentioned below removes the ambiguity.
> 
>> This might be pretty useful in some situations, but I am not sure if the semantic complexity that it introduces is worth it.
>> 
>> Another example of how this could be useful: 
>> 
>> I made a bare-bones rational number type <https://gist.github.com/hooman/6e08c48e1e06ee19e06e5b09f664f9be> for Swift a while ago. I would love to be able to overload “/“ operator to create fractions (rational numbers) instead of dividing two integers. 
>> 
>> If I overloaded “/“ to return rational (Int / Int -> Rational), the result type of the operator would become ambiguous for every use of it with integer operands.
> 
> That isn’t the way the type checker works. If you use an explicit type to contextualize the expression, there is no ambiguity. For example this works without any ambiguity.
> 
> struct Rational {}
> func / (lhs: Int, rhs: Int) -> Rational { return Rational() }
> func + (lhs: Rational, rhs: Rational) -> Rational { return Rational() }
> 
> func use(r: Rational) {}
> 
> let x: Rational = (1 / 2) + (2 / 3)  // Rational result type, no ambiguity
> use(r: (1 / 2) + (2 / 3))  // Rational argument type, no ambiguity
> let y = (1 / 2) as Rational    // Calls func/(Int,Int)->Rational
> 
> Mark
> 
>> It would be nice if I could prioritize my overload of “/“ over stdlib definition to resolve the ambiguity. 
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161013/61ae2284/attachment.html>