> On Nov 27, 2016, at 7:03 PM, David Sweeris <[email protected]> wrote: > > > On Nov 26, 2016, at 23:52, Robert Widmann <[email protected] > <mailto:[email protected]>> wrote: > >> Under the old behavior they must have identical declarations, that includes >> precedence. We specifically had to modify the precedences of some stuff in >> Operadics to match Runes because of this and it worked just fine. >> >>> On Nov 27, 2016, at 12:43 AM, David Sweeris <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On Nov 26, 2016, at 22:02, Dave Abrahams <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> on Sat Nov 26 2016, David Sweeris <davesweeris-AT-mac.com >>>> <http://davesweeris-at-mac.com/>> wrote: >>>> >>>>>> On Nov 26, 2016, at 17:19, Robert Widmann via swift-evolution >>>>>> <[email protected] <mailto:[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. >>>> >>>> differnt precedences => not perfect duplicates, right? >>> >>> That's a good question... I don't know... The compiler keeps track of >>> functions by their "fully qualified" name, i.e. "MyLib.+(Int, Int)->Int", >>> right? >>> >>> Swift's syntax only allows us to declare precedence on a per-operator >>> basis. Does the compiler track precedence on a per-function basis anyway, >>> and if so, how would you specify which precedence you want at the call >>> site? Aside from parentheses, I mean. >>> >>> - Dave Sweeris > > I don't know what "operatics" or “runes” are. Based on the context I’d guess > they’re two parts of the standard library, but I'd like to be sure. >
Operadics and Runes are libraries that export nothing but operator declarations. The former is put out by my org., TypeLift <https://github.com/typelift/Operadics/commit/c65e6355e22282a89d68a8a2d594a32c36c1e7b0>, he latter is put out by ThoughtBot <https://github.com/thoughtbot/Runes>. > Either way, though, I'm not sure this addresses my primary objection (which I > wrote the wrong way around in my earlier email). Suppose a library does this: > //ALib > infix operator • : MultiplicationPrecedence > extension Double : IntegerArithmetic {...} > func • <T: IntegerArithmetic> (lhs: T, rhs: Array<T>) -> Array<T> { return > rhs.map {lhs * $0} } > func + <T: IntegerArithmetic> (lhs: T, rhs: Array<T>) -> Array<T> { return > rhs.map {lhs + $0} } > And another library does this, which is an easy copy/paste error to make, > since everything still works as long as you only test single-operator > expressions: > //ABuggedLib > infix operator • : AdditionPrecedence > //Some convenience functions for getting Ints into your Doubly goodness > func • (lhs: Int, rhs: Array<Double>) -> Array<Double> { return rhs.map > {Double(lhs) * $0} } > func + (lhs: Int, rhs: Array<Double>) -> Array<Double> { return rhs.map > {Double(lhs) + $0} } I’m gonna cut you off right here: These are not identical declarations and were an error under even the old scheme of things. This is not what we are talking about.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
