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
