[swift-evolution] Some concerns on custom operators

[Robert Widmann]

> On Nov 27, 2016, at 7:03 PM, David Sweeris <davesweeris at mac.com> wrote:
> 
> 
> On Nov 26, 2016, at 23:52, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> 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 <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>> 
>>>> 
>>>> On Nov 26, 2016, at 22:02, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> 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 <swift-evolution at swift.org <mailto: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. 
>>>> 
>>>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161127/685ba6e0/attachment.html>