<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-11-28 5:09 GMT+03:00 Robert Widmann via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<span class=""><br><br>
> 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.<br>
<br>
</span>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.</blockquote><div><br></div><div>Would allowing duplicate precedence group declarations solve the problem? AFAIK, operators are already merged this way.</div></div></div></div>