golang-samber-molisted

# samber/mo value and computation types Read `go.mod`, imports, public signatures, conversions, serialization, database scans, and tests before changing a mo type. Confirm APIs in the pinned release; method and subpackage surfaces evolve independently. ## Choose the value model | Type | Use when | Boundary question | | --- | --- | --- | | `Option[T]` | A value can be present or absent without failure | Is empty distinct from the zero value? | | `Result[T]` | A computation has a success value or Go error | Must callers retain `errors.Is`/`errors.As`? | | `Either[L, R]` | Both alternatives are meaningful domain values | Which side convention is already established? | | `Either3` through `Either5` | A closed set needs more variants | Would a named domain type communicate the cases better? | | `Future`, `IO`, `Task`, `State` families | Existing code relies on their evaluation model | Who starts, waits for, cancels, or owns the computation? | Give nested types an explicit meaning. `Result[Option[T]]`, for example, can distinguish failure from a successful absence, but only when callers preserve both cases. ## Constructors and extraction Representative constructors include `Some`, `None`, `TupleToOption`, `PointerToOption`, `Ok`, `Err`, `TupleToResult`, `Left`, and `Right`. Verify the exact generic arguments and conversion helpers before use. Prefer checked extraction such as `Get`, `OrElse`, matching, or conversion back to ordinary Go returns. `MustGet` panics for the absen