[swift-evolution] Some concerns on custom operators

Anton Zhilin antonyzhilin at gmail.com
Mon Nov 28 04:58:10 CST 2016

2016-11-28 5:09 GMT+03:00 Robert Widmann via swift-evolution <
swift-evolution at swift.org>:

> 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.
> > 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.

Would allowing duplicate precedence group declarations solve the problem?
AFAIK, operators are already merged this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161128/0fe3b767/attachment.html>

More information about the swift-evolution mailing list