Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add .Unpack() to Result and friends to mirror lo Tuple family OR add .Get() to lo Tuple family to mirror mo Result/Option #40

Open
jcbhmr opened this issue Apr 26, 2024 · 1 comment

Comments

@jcbhmr
Copy link

jcbhmr commented Apr 26, 2024

I would like to be able to do this:

type myUnpack[T any, U any] interface {
  Unpack() (T, U)
}

func MyFunc() <-chan myUnpack[int, error] {
  c := make(chan myUnpack[int, error])
  go func(){
    defer close(c)
    time.Sleep(200 * time.Milliseconds)
    // c <- mo.Option
    // c <- lo.Tuple2
    // c <- mo.Result
    // c <- whatever
  }()
  return c
}

so that my users downstream don't have to really care whether they got a Result or a Tuple2 or what; they just do this in their code and it works:

import "github.com/jcbhmr/thelib"

func main() {
  v, err := (<-thelib.MyFunc()).Unpack()
  if err != nil {
    log.Fatal(err)
  }
  log.Printf("The result is %d", v)
}

basically I want to have a nice "this is the way you do it" pattern to pass through 2x tuple of values in a chan. i sometimes use a lo.Tuple[int, bool] and sometimes a mo.Result[int] and sometimes an mo.Option[int] all to represent basically the same thing; I want the user to just .Unpack() the chan result and not worry about any additional .map() or other magic this-library-specific details. just unpack it into idiomatic go multivalues lol. does that make sense? i don't want the user to even need to be aware that I'm using lo or mo; they should just .Unpack() to get the plain go-like multireturn (T, bool) or (T, error) or (T, U) pair.

my suggesting to achieve this utopia of .Unpack() meaning "make into go-like multireturn" is to add a .Unpack() to Result in this package and any other related unpackable types like maybe Option -> (T, bool) or something

NEED TO MENTION that this COULD work with .Get() too! Result and Option in this package already implement .Get() idiomatically; its just that the sister package lo doesnt implement Tuple2.Get() https://pkg.go.dev/github.com/samber/lo#Tuple2

type myGet[T any, U any] interface {
  Get() (T, U)
}

func MyFunc() <-chan myGet[int, error] {
  c := make(chan myGet[int, error])
  go func(){
    defer close(c)
    time.Sleep(200 * time.Milliseconds)
    // c <- mo.Option
    // c <- lo.Tuple2
    // c <- mo.Result
    // c <- whatever
  }()
  return c
}
import "github.com/jcbhmr/thelib"

func main() {
  v, err := (<-thelib.MyFunc()).Get()
  if err != nil {
    log.Fatal(err)
  }
  log.Printf("The result is %d", v)
}

tldr is either .Unpack() or .Get() would be nice to have on all these Option Result Tuple types to convert them back to go-idiomatic multivalues that are not lib-specific Option/Result/Tuple types

@jcbhmr jcbhmr changed the title Add .Unpack() to Result and friends to mirror lo Tuple2 OR add .Get() to lo Tuple2 to mirror mo Result/Option Add .Unpack() to Result and friends to mirror lo Tuple2 OR add .Get() to lo Tuple family to mirror mo Result/Option Apr 26, 2024
@jcbhmr jcbhmr changed the title Add .Unpack() to Result and friends to mirror lo Tuple2 OR add .Get() to lo Tuple family to mirror mo Result/Option Add .Unpack() to Result and friends to mirror lo Tuple family OR add .Get() to lo Tuple family to mirror mo Result/Option Apr 26, 2024
@samber
Copy link
Owner

samber commented Apr 28, 2024

What about adding a .AsTuple() lo.Tuple2[A, B] method to Option, Result, Either?

In that case, it would be compatible with lo.UnzipX.

IMO, we should not create any dependency between both libraries, this is why I like your suggestion. Maybe lo.UnzipX should accept interface, instead of tuple.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants