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 <[email protected]> wrote: > >> On Nov 26, 2016, at 3:19 PM, Robert Widmann <[email protected]> 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 <[email protected]> wrote: >>> >>> >>>> On Nov 10, 2016, at 7:23 AM, Jay Abbott via swift-evolution >>>> <[email protected]> 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 >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
