[swift-evolution] Some concerns on custom operators
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
Would allowing duplicate precedence group declarations solve the problem?
AFAIK, operators are already merged this way.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution