[swift-evolution] Some concerns on custom operators

[Robert Widmann]

That is what was happening for me at the time.  Operadics was exporting bind (>>-), ap (<*>) and fmap (<^>), and SwiftCheck was pulling in Operadics inline in the non-SPM build.  The two modules were literally trying to export the same operators with the same precedencegroup declarations.  My definition of “perfectly identical” covers this case.

> On Nov 27, 2016, at 9:01 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Nov 26, 2016, at 3:19 PM, Robert Widmann <devteam.codafi at gmail.com> wrote:
>> Just gotta field a version of that proposal that doesn’t “look like Haskell” :)
>> 
>> 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?
> 
> The definition of "perfect duplicates" is more complex now.  It would be easy to ignore duplicates that name the same precedencegroup, but that's probably not what's happening here.

In that case there is a nice structural equality that falls out of the current way things are defined, more so than before given that we can use the relative precedences (and given that most libraries don’t set up precedencegroup lattices that are complex as TypeLift does).  Essentially, the problem is verifying a bisimulation with alpha-equivalence at all the edges.  

> 
> John.
> 
>> 
>>> On Nov 10, 2016, at 10:54 AM, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> 
>>>> On Nov 10, 2016, at 7:23 AM, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Would it make sense to allow some kind of operator aliasing on import, so that developers can at least work-around library conflicts?
>>> 
>>> Definitely. I think something like the import improvements Robert Widmann was proposing a while back are sorely needed, not only for operators but for managing conflicts in general.
>>> 
>>> -Joe
>> 
>