[swift-evolution] Some concerns on custom operators

[Robert Widmann]

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> wrote:
> 
>> 
>> On Nov 26, 2016, at 22:02, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Sat Nov 26 2016, David Sweeris <davesweeris-AT-mac.com> wrote:
>> 
>>>> 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. 
>> 
>> 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

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