Proposal: Go2: Tuple type

[maxekman]

I propose the addition of a new built-in type tuple and that functions should always returns a single value:

// Single return value of int.
func f() int {
  return 1
}

// Single return value of the tuple (int, error).
func g() (int, error) {
  return 1, errors.New("error")
}

Destruction of the new tuple type should be handled as before when returning multiple arguments, in addition to being able to store the tuple in a var with separate destruction:

// Destruct inline with call.
i, err := g()

// Destruct from tuple var.
r := g()
j, err2 := r

A naive idea for how defining a user tuple type could look:

type Pair tuple (int, int)

My proposal is inspired by the ideas and problems from this article about Monads in Go by @awalterschulze: https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/

In the article he describes composing functions that return errors, for example (not from the article):

func f() (int, err) {
  return 1, nil
}

func g(x (int, err)) (int, err) {
  return x
}

// Returns 1 and nil from f().
val, err := g(f())

Having these additions to the language would allow for some interesting functional concepts to be implemented cleanly.

I have tried to look for earlier proposals without finding any, please correct me if it has been brought up before. Would love to hear your thoughts!

Thanks,
Max Ekman

[ianlancetaylor]

Seems to me that I could write your example as:

func f() (int, error) {
  return 1, nil
}

func g(i int, e error) (int, error) {
  return i, e
}

// Returns 1 and nil from f().
val, err := g(f())

Yes, using tuples is very slightly shorter, but the benefit seems quite small. Is there another way that tuples provide a bigger benefit?

[maxekman]

Yes in that case you are right.

I missed a small detail from the example in the article, there was another argument after the int, error pair. The specific section in the article of interest is called “Squinting” (I couldn’t link directly). Here is the initial example exactly from that section that will not currently compile:

func f() (int, error) {
    return 1, nil
}

func g(i int, err error, j int) int {
    if err != nil {
        return 0
    }
    return i + j
}

func main() {
    i := g(f(), 1)
    println(i)
}

[ccbrown]

Allowing functions to return either one value (the tuple) or multiple values (the components of the tuple) based on context-only rather than an explicit syntax seems like it has potential to make things a bit confusing.

func f() (int, int) {
    return 1, 2
}

func foo(args ...interface{}) {
    // ???
}

foo(f())

Is args []interface{}{(1, 2)} or []interface{}{1, 2}?

To address the kind of thing in your example, I would be a much bigger fan of just allowing multi-value returns to automatically expand into function arguments, without the addition of a tuple type. See #973 (comment) though.

[maxekman]

Thanks for the link to the interesting comment! Gives some insight. However, it would not be a problem if all functions always returns a single value. In that case the problem lies in allowing destruction when calling another function or not.

In your case with my proposal args would have the value []interface{}{(1, 2)}.

[deanveloper]

I'd definitely rather have it expand to []interface{1, 2}. Also, I personally don't like the idea of having a tuple type that gets expanded into whatever it assigns. After learning several languages that have features such as array restructuring and tuple destructuring, it starts to get confusing on whichever syntax I should use to destructure the tuple. I already have this issue with needing to remember if the ellipsis for a "spread" operator comes before or after the array (ie fmt.Println(array...).

Also, typically tuples allow for individual access to the returned arguments. This would hurt Go, as it would encourage the behavior of ignoring errors and possibly leaking resources (ie someMethod(os.Open("file.txt")[0])). This proposal doesn't offer a way to index into a tuple.

Either way, I think we might want to just add the features that we would want from tuples into multiple-return, rather than introducing an entirely new concept

[beoran]

You can already implement a tuple in Go as it is now, look at the following example:
https://github.com/kmanley/golang-tuple

Furthermore, changing the language to remove multiple return is likely to break all existing Go code, and hence seems unadvisable.

[maxekman]

Yes, I know a tuple type can be implemented. However by having a tuple as a native type the above mentioned composition pattern (and other functional patterns) can be implemented in a clean fashion. Please read the linked article if you haven’t to see what could be achieved cleanly with native tuples.

Regarding breaking existing code it will of course happen in varying degrees depending on how this would be implemented if accepted. Note however that this proposal is labeled for Go 2, which would allow backward incompatible changes (although encouraging to minimize them).

[urandom]

@ianlancetaylor

Having the return type be a fully fledged tuple type has some added benefits. The biggest one being that you can finally pass the result of a function through a channel without having to manually convert it to a struct. You can also define methods on them, which is always nice.

It also seems like there aren't a lot of negatives. Seems to be a backwards compatible change, by just promoting a quirk in the spec to a proper type like any other.

[maxekman]

Two really good points there which I hadn’t thought about! Especially the last one; imagine a 2d point type with methods for example.

[ianlancetaylor]

It might be interesting to consider whether we can introduce a conversion between a function result and a struct with the same types, as in the following. That might possibly be a smaller change to the language that achieves similar benefits.

type Pair struct {
    i int
    s string
}

func F() (int, string) { ... }

func G() chan Pair {
    c := make(chan Pair)
    go func() {
        c <- Pair(F())
    }()
    return c
}

If we introduce a new kind of type we need to discuss things like how to initialize them, how to convert them, how to decompose them, and what composite literals look like. It seems to me that most of the answers for a tuple will be the same as the answers for a struct. That suggests that tuple doesn't add much to the language. So let's think about what tuple does add, and it would take to make that work with struct.

[bcmills]

In my experience, tuples are almost always less clear than the equivalent structs with named fields.

See related experience reports from Google's Guava libraries in Java, the Chromium project in C++, and numerous other sources.

(Note that Python's tuples are rendered somewhat less harmful through the use of namedtuple, which adapts a tuple into a struct — but then why not return a struct in the first place?)