> On Nov 26, 2016, at 17:19, Robert Widmann via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
