This PR converts MutableAntichain::frontier from a Vec<T> to an Antichain<T>. In addition to a bit more code reuse, this allows MutableAntichain to expose a &Antichain<T> type rather than an AntichainRef<T>, which can be annoying to relate back to antichains (e.g. to join with, say). One can always go from an &Antichain<T> to an AntichainRef<T> with the borrow() method, but not the other way around.
The downside to scrutinize is the moment where we update frontier rebuilding the antichain. To my eyes, we do almost the same linear work per element, except that we additionally consider evicting elements that we know we wont have to evict. I'm ok losing that performance for the type clarity, or perhaps adding some from_ordered_iter to Antichain.
This PR converts
MutableAntichain::frontierfrom aVec<T>to anAntichain<T>. In addition to a bit more code reuse, this allowsMutableAntichainto expose a&Antichain<T>type rather than anAntichainRef<T>, which can be annoying to relate back to antichains (e.g. tojoinwith, say). One can always go from an&Antichain<T>to anAntichainRef<T>with theborrow()method, but not the other way around.The downside to scrutinize is the moment where we update
frontierrebuilding the antichain. To my eyes, we do almost the same linear work per element, except that we additionally consider evicting elements that we know we wont have to evict. I'm ok losing that performance for the type clarity, or perhaps adding somefrom_ordered_itertoAntichain.cc: @jkosh44