version: "1.0.0" name: golang-samber-lo description: Implement, review, or optimize typed collection transformations with github.com/samber/lo and its parallel, mutable, iterator, or experimental subpackages. Use when a project already uses lo or deliberately selects it for collection-oriented code. license: MIT

samber/lo collection helpers

Inspect go.mod, imports, the repository's Go version, nearby loops or helper chains, and tests. Compare the selected lo release with the standard slices, maps, and iterator APIs before choosing an implementation.

Choose the package deliberately

Subpackages appear at different points in lo's history, so confirm each import in the pinned module:

Use the core package for ordinary eager transforms. Select parallel or mutable variants from measurements and ownership evidence. Iterator pipelines fit large or partially consumed sequences when the project's toolchain supports the package.

Match the operation to its semantics

Representative core families include:

• Map, Filter, Reject, Reduce, and their error-aware variants;
• Find, Contains, Every, Some, First, and Last;
• GroupBy, KeyBy, Associate, PartitionBy, and map helpers;
• Chunk, Flatten, Uniq, Zip*, and Unzip*;
• pointer, tuple, channel, retry, debounce, and throttle helpers in releases that provide them.

Check the exact signature rather than translating from a remembered catalog. Callback indexes, early-error behavior, duplicate resolution, and whether order is preserved vary by function family. Map iteration remains nondeterministic unless the code sorts keys or results explicitly.

Preserve ownership and representation

Establish before replacing a loop:

• whether nil must remain distinguishable from an allocated empty result;
• whether duplicate keys use first-wins, last-wins, or an error;
• whether partial results are retained after a callback error;
• whether elements contain pointers, slices, or maps that remain shared;
• whether the original slice or backing array is still used elsewhere.

The core package returning a new slice does not deep-copy referenced elements. Mutable helpers can affect every alias of the source backing array. Parallel callbacks must be safe to run concurrently and should not update shared state without synchronization.

Error and panic variants

Prefer an error-returning helper when the callback can fail and the caller needs the failing result. Confirm whether that variant stops on the first error, preserves input order, and returns partial output. Must* and panic-recovery helpers are suitable only where panic is already the intended control contract.

Readability and performance

A helper chain is useful when each stage has one obvious purpose. An explicit loop often better expresses cancellation, indexed diagnostics, several branches, partial output, or bounded I/O concurrency.

Benchmark the exact dataset and callback before moving to parallel, mutable, iterators, or SIMD. Include allocations, result ordering, and small-input overhead; do not infer a speedup from package names.

Verification

Add focused tests for nil and empty input, duplicates, stable ordering, callback errors, aliasing, and any parallel execution. For iterator code, test early termination and ensure source cleanup still runs. Use go test -race when callbacks or mutable data can be shared.

References

• package documentation
• repository and subpackages
• documentation