Slice: Add GroupBy func

[donutloop]

Group by: split slice into two groups, applies on each slice element a
predicate func to categorize this element.

Changes

• Add groub by func
• Add test case for this func

[donutloop]

@duke-git please review

[codecov-commenter]

Codecov Report

Merging #10 (935c4f6) into main (94b1a1d) will increase coverage by 0.08%.
The diff coverage is 86.66%.

@@            Coverage Diff             @@
##             main      #10      +/-   ##
==========================================
+ Coverage   78.12%   78.21%   +0.08%     
==========================================
  Files          22       22              
  Lines        1472     1487      +15     
==========================================
+ Hits         1150     1163      +13     
- Misses        215      216       +1     
- Partials      107      108       +1     

Impacted Files	Coverage Δ
slice/slice.go	79.30% <86.66%> (+0.30%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 94b1a1d...935c4f6. Read the comment docs.

[duke-git]

@duke-git please review

@donutloop ，thanks, GroupBy func is helpful.

[donutloop]

@duke-git Almost all functions that currently use reflection to achieve reusability can be migrated to generics (a feature of 1.18). Can we open a branch v2 and start to migrate from reflection to generics soon?

Ref: https://go.dev/blog/go1.18beta1

[duke-git]

@duke-git Almost all functions that currently use reflection to achieve reusability can be migrated to generics (a feature of 1.18). Can we open a branch v2 and start to migrate from reflection to generics soon?

Ref: https://go.dev/blog/go1.18beta1

@donutloop. Thanks, good suggestion. It's necessary to replace reflection into generic. I do have the plan. The question is that generic support in Go 1.18 Beta which is a preview release, not production release. From my point of view, it's unstable for now. will it change or has minor adjustments in future version go？My suggestions are as follows: please review.

1. Can we migrate from reflection to generics when go has a production release for generics? (maybe couple months later, not sure)
2. After we migrate generics, we still need to support interface (reflection) for users who use go version under v1.18.
   (v1.x.x for interface reflection, v2.x.x for generics)

[donutloop]

@duke-git

1.) I don't expect any major design changes because a beta API should already be in a frozen state. My recommendation, we can create a branch develop V2, and then start to develop the generic form of all affected functions.
2.) It definitely makes sense to not immediately drop the support of the reflection versions.

Let me know what you think

[duke-git]

migrated

@duke-git

1.) I don't expect any major design changes because a beta API should already be in a frozen state. My recommendation, we can create a branch develop V2, and then start to develop the generic form of all affected functions. 2.) It definitely makes sense to not immediately drop the support of the reflection versions.

Let me know what you think

@donutloop. Agree. I spent a couple of hours understand the go generics and try to rewrite some funcs (slice/slice.go, Map, Filter, ForEach). I find the code is concise and elegant after use generics, although generics syntax is a bit messy。I have checkout branch v2, we can migrate to generics in slice/slice.go step by step. How about it?