Road to V2

[samber]

I'm opening an issue for discussion about v2.

There is no immediate requirement for going forward a major release, but building some spec for v2 is a great way to ensure the new helpers to come, will respect standards until then.

Breaking changes in method signature:

• helpers with index (Spec: about index argument in iteratee #579)
• helpers with callbacks:
  • Remove deprecated helper IsSortedByKey (renamed to IsSortedBy) #696
• helpers using lo.Entry type (Provide methods to convert Tuple2 to Entry and Map. #597)
• mutable helpers
  • Reverse mutating? #160
• variadic:
  • Implement Min/Max as variadic functions #224
• other bugs:
  • [v2] ChunkString behavior inconsistency with Chunk for empty input #788
  • Add a zip helper that stops at the shortest input #877

If you have any improvements in mind, please open an issue mentioning v2. I will add it to this list.

[loggerhead]

Since lo.ToPtr is often used, can we change it to a shorter name, like lo.Ptr?

[gurgeous]

Thanks so much for creating this great library! We really appreciate the work you are doing. I am using it heavily in my project... One thing that might be nice for v2 is to have an explicit goal to close or merge all open PRs and issues? I know folks have offered to pitch in. Would that be helpful?

Personally I'd also like to see Push/Pop/Shift/Unshift sometime soon :) I know there is a PR for that. Other popular PRs:

[kaitsubaka]

Thank you for creating this fantastic library! I do have one concern regarding the current error handling approach. In Go, panics should generally be reserved for truly exceptional circumstances, where recovery is not possible, or when the program is in an unrecoverable state. For more predictable and controlled error handling, it is more idiomatic and safer to return an error and allow the caller to decide how to handle it.

My proposal is to update the function signatures that currently use panics to instead return errors. This would give users of the function the flexibility to determine how they want to handle the error, whether that involves logging, retrying, or using a fallback strategy.

Since the MustX functions are already implemented, they could be used to wrap functions where panics are necessary, ensuring that they only panic when absolutely required.

I noticed there is already a merge request implementing error handling with lo.FuncErr signatures, but I believe this approach should be the default behavior moving forward.

Additionally, we can use the %w format in fmt.Errorf to wrap custom errors. This would allow us to leverage Go’s error wrapping feature, providing better error handling and making it easier to use the standard library's error inspection functions, such as errors.Is and errors.As.

[mimol91]

@samber Can we change buffer* to be an iterator?

[samber]

@mimol91 I would suggest using the "it" sub-package (or make a PR if a helper is missing.

In some case, you should be interested by samber/ro for a stream data structure.

[amitdixit]

This is a awesome package. Having come from 17 years of C# background where Linq is de-facto for operations on Collections. This package really helped us going. Eagerly awaiting for V2.