Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge Merge/MergeBy/MergeJoinBy implementations #711

Closed

Conversation

Philippe-Cholet
Copy link
Member

@Philippe-Cholet Philippe-Cholet commented Jul 2, 2023

Merge and MergeBy are moved from "adaptors" to "merge_join" modules.
Then Merge, MergeBy and MergeJoinBy are now instances of a new (common and private) struct: InternalMergeJoinBy.
Internally, instead of OrderingOrBool and FnMut(&L, &R) -> Out, we use MergePredicate<L, R, Out=...> (Out being Ordering or bool).
And with MergeFuncT and MergeFuncLR also kept private, the functions return those types:

merge                      -> InternalMergeJoinBy<I, J, MergeFuncT<MergeLte>>
merge_by                   -> InternalMergeJoinBy<I, J, MergeFuncT<F>>
merge_join_by(...bool)     -> InternalMergeJoinBy<I, J, MergeFuncLR<F, bool>>
merge_join_by(...Ordering) -> InternalMergeJoinBy<I, J, MergeFuncLR<F, Ordering>>

The only changes for an external user:

  • MergeJoinBy sadly requires now a fourth type (it was that or share the internal MergeFuncLR publicly).
  • MergeJoinBy now implements FusedIterator too.

Closes #701

PS: In fn merge_join_by, the constraint T: OrderingOrBool<I::Item, J::Item>, has been removed. Even if the documentation is clear, we could add it back in some way if you want.

Philippe-Cholet and others added 8 commits June 17, 2023 17:56
To get rid of `const SAME: bool`, I wrap the function `F` in `MergeFuncLR` and `MergeFuncT`.
Those `MergeFuncLR/T` have a parameter  `T` (phantom field) to not have conflicting implementations of `MergePredicate<L, R>`.

In `merge_join_by` definition, in order for the compiler to keep guessing left/right types, I kept `F: FnMut(&Self::Item, &J::Item) -> T`. But to not add `F: MergePredicate<Self::Item, J::Item>` that felt duplicate, I removed `T: OrderingOrBool...`, the user might lose `OrderingOrBool` information.
And I simplify `MergeFuncLR` and `MergeFuncT` to "tuple structs".
Basically because `PutBack<Fuse<I>>` is fused no matter if `I` is or not. Same for `J`.
@phimuemue
Copy link
Member

Hi @Philippe-Cholet, thanks for this. I try to pick this up, but I am very unsure that MergeJoinBy really needs a fourth type parameter, so I for now only cherry-picked the first commit here.

@Philippe-Cholet
Copy link
Member Author

@phimuemue A bit disappointed, I started again and to my own surprise I quickly found a way (fresh eyes I guess). So 0a3f122
It results in a big type definition but it works.

@Philippe-Cholet
Copy link
Member Author

I'm closing this. This is the result of some useful experiments but became too messy to be properly reviewed and it deserves a cleaner PR I'm currently working on.
At least, the first commit has been cherry-picked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Merge MergeBy and MergeJoinBy
2 participants