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.la...@apple.com> wrote:
> 
> 
>> On Oct 13, 2016, at 5:37 PM, Hooman Mehr via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> 
>>> On Oct 13, 2016, at 3:31 PM, Rick Mann via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to