Add a Join() function to the lo package

[eliotttak]

Describe your changes

I added a Join() function to the lo package.
It takes a collection and a separator (that can be any type) and returns a string that contains
every item, separated by the specified separator.

It uses fmt to convert list items and separator to string, and a strings.Builder to construct it.
I created an example on pkg.go.dev but because the import path is github.com/samber/lo, it will be available only if you accept the PR.

I wrote various tests in ./slice_test.go. Feel free to look at them if you want to verify, I tried to cover every case where my function could bug.

Checklist before requesting a review

• 👓 I have performed a self-review of my code
• 👶 This helper does not already exist
• 🧪 This helper is tested
• 🏎️ My code limits memory allocation and is fast
• [?] 🧞‍♂️ This helper is immutable and my tests prove it
• [?] ✍️ I implemented the parallel, iterator and mutable variants
• 🔬 An example has been added to lo_example_test.go
• ⛹️ An example has been created on https://go.dev/play and added in comments
• 📖 My helper has been added to documentation
  • in README.md
  • in docs/data/*.md
  • in docs/static/llms.txt

Conventions

• Returning (ok bool) is often better than (err error)
• panic(...) must be limited
• Helpers should receive variadic arguments when relevent
• Add variants of your helper when relevant:
  • Variable number of arguments: lo.Must0, lo.Must1, lo.Must2, ...
  • Predicate with index: lo.SliceToMap vs lo.SliceToMapI
  • With lazy callback: lo.Ternary vs lo.TernaryF
  • ...

[eliotttak]

Fixes #351.

[samber]

The fmt.Fprintf seems very hacky to me: only works well for strings and ints. And strings can be joined by strings.Join. I would have proposed lo.JoinBy(slice, sep, serializer) but this is pretty much the same than strings.Join(lo.Map(slice, serializer), sep) so i don't feel very useful to me.

WDYT ? Do you have some use case to demonstrate ?

[eliotttak]

WDYT ? Do you have some use case to demonstrate ?

I already had to join a []bool, and as you said I had to make something like this:

myBools := []bool{true, false, true}
joined := strings.Join(lo.Map(myBools, fmt.Sprint), ", ")
fmt.Println(joined)

I don't find it very clear, and I'ld prefer my method, which lets me to do like this:

myBools := []bool{true, false, true}
joined := lo.Join(myBools, ", ")
fmt.Println(joined)

Don't you think this method is more readable?

The fmt.Fprintf seems very hacky to me: only works well for strings and ints.

If the user wants to convert each element to string manually, they can do it with your method (strings.Join(lo.Map(slice, serializer), sep)). The mine is only for simple slices (even if there's nothing stopping you from concatenating, for example, []struct{a int, b string}).

[mattg-imprint]

tl;dr - This function doesn't seem generic enough for samber/lo. Maybe there's another formatting or debug output package where it would be a better fit.

I agree that serialization format is subjective and should be done by the caller rather than embedded inside the samber/lo function. For the bool example, strconv.FormatBool is a more natural conversion to a string before serialization. Like

myBools := []bool{true, false, true}
joined := strings.Join(lo.Map(myBools, strconv.FormatBool), ", ")

It's a pretty big assumption to make that the user want's the list of bools to be true/false. If you want 1/0 or t/f or yes/no or oui/non this wouldn't be useful.
Also, the separator as an any seems sketchy. A string join separator should just be a string like strings.Join uses.