[swift-evolution] Some concerns on custom operators

[David Sweeris]

> On Nov 26, 2016, at 17:19, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Just gotta field a version of that proposal that doesn’t “look like Haskell” :)
Is there something wrong with Haskell's approach to imports? I don't know how they do it, so I'm unaware of any pros/cons to their approach. The ":)" makes me think I'm missing something...

> Seriously, though, would there be any objection to restoring the old behavior of just silently ignoring perfect duplicates of operator definitions across frameworks sans proposal?
Yeah, it could silently change how statements get evaluated, if I start writing code using one library's operators, then import a 3rd library which defines the same operators but with different precedences. There's probably not any ambiguities if the two libraries don't define the same actual function signatures (like one defines `+(Double, Double)->Double` and one defines `+(Int, Int)->Int`), but that doesn't help if the both define the same operator with the same signature with different precedences. And what if you want to define `+(Double, Int)->String`? Does the + operator take its precedence from the first library or the second?

Or for a slightly more plausible example, what if a library defines `*(Double, Int)->Double` and it does exactly what you'd expect it to do, but for whatever reason it was given the wrong precedence. Suddenly, code like this:
    let x = someDouble * 4 + 3 // 4 and 3 are inferred to be doubles
changes to this:
    let x = someDouble * 4 + 3 // 4 is inferred to be an Int, and 3 is inferred to be a double
This (I think) gives a different answer, purely because of the unexpected change in precedence. This would be especially hard to debug, since `let x = someDouble * 4` by itself would still give the correct answer even though it'd be using the "wrong" function.



What about allowing users to import a library's global functions and operators separately from its types? Or optionally importing the global stuff into a namespace (obviously this would necessitate adding namespace support)?

- Dave Sweeris