Suggestion: allow destructuring tuple in function parameters

[sporto]

I found myself doing this very often, which feels verbose

fn something(tuple) {
  let #(a, b) = tuple
  ...
}

Would be great to be able to do:

fn something(#(a, b)) {
   ...
}

And maybe if you want to keep the tuple as a parameter:

fn something(#(a, b) as tuple) {
   ...
}

Thanks

[lpil]

I'm not immediately in favour of this because it seems like another way to get values from tuples without much of an obvious advantage over the methods we have today. I'd like to be quite conservative with features in Gleam, only adding things if they enable something new or provide a big UX improvement.

For me this doesn't meet that mark, but perhaps it will resonate more with the community. I'll convert this to a discussion so people can share their thoughts.

RE that example, you can also do this

fn something(tuple: #(a, b)) -> a {
  tuple.0
}

[michallepicki]

From my point of view tuples (and one-constructor custom types) would be the only types where this can be done in the function head, without pushing for multiple function clauses support. I would find this mostly useful in initial stages of code development, where I'm prototyping some API and want to "just" pass some data around, and expect the fields to change. So I think it shouldn't cause technically any issues and I do agree with @sporto that it makes code a tiny bit more concise in that particular scenario.

But it would be "different" than any other type...

Alternatives that require only a bit more typing are:

• using .0, .1 etc (disadvantage: fields aren't named for readability)
• passing multiple arguments separately instead (the disadvantage here is that it doesn't work nicely with the pipeline |> operator)
• destructuring the tuple at the beginning of the function
• defining your own one-constructor custom type

I personally think destructuring at the beginning of the function is not that much of a hassle, allows to give names to the fields, and has a very natural and easy code refactoring transition to a custom type.

[bfeitknecht]

How about some inspiration from haskell's as-pattern syntax?

fn f(t@(a, b): #(A, B)) -> Nil {
  echo t
  echo a
  echo b
}

[lpil]

We already have that pattern, the as keyword!

[inoas]

I am not in favour of encouraging to use tuples (I consider them unnamed singleton types) over gleam records.

But even for records, I think keeping the function signature easy to read is worth a lot and if type signatures are added things are complex enough to grasp.