No syntax tuples.

[CrowdHailer]

One feature I discovered only when Louis told me about it was that case statements could have multuple values.
i.e.

case a, b {
  1, 2 -> do_thing() 
  _, _ -> do_other_thing()
}

I assume that under the hood this is handled as a tuple?
Could other parts of gleam handle multiple values like this, I don't see any reason why not.

For example

fn foo () {
  1, 2
}

fn main() {
  let x: tuple(Int, Int) = foo()
  let a, b = foo()
  assert 1, b = foo()
}

This would be a suggestion, instead of a short tuple syntax see #1005
Maybe that ship has sailed, but it seems consistent with case statements and has precedent in language like Go.
https://gobyexample.com/multiple-return-values

[lpil]

It's not quite what Go does, they don't have tuples at all, just a syntax for returning more than one argument. You can't save all the values to one variables for example.
This is however exactly what OCaml does!

It's not possible in Gleam today because it would be ambiguous. Is f(1, 2) a call to a function that takes 2 arguments, or is it a call to a function that takes one argument that is a tuple? In OCaml there is no difference, but in Gleam we don't have autocurrying and we want Erlang/Elixir/etc interop so they have to be different.

Additionally it would mean that we also need to use ; between elements in lists as OCaml does, which I think would be unpopular.

[CrowdHailer]

I think for this approach I wouldn't expect to be able to use no syntax tuples everywhere. i.e. f(1, 2) is always a two arity function. f(tuple(1, 2)) would be required for tuples.

I very rarely construct things like tuples/Records in the arguemtns of a function call. Mostly I take a tuple as an arg because they are a set of things that travel together. i.e.

let t = 1, 2
// later
f(t)

So I believe that having multi assignment/return would remove the majority of my use of the explicit word tuple. I guess that might be personal to my approach.

[lpil]

From writing a lot of Go I can say that having multiple returns but not tuples is very frustrating. You don't notice how often you assign a tuple to a variable until you can't.

Having two different contextual tuple syntaxes would make the language harder to understand and more complicated to implement. I don't think that's a very good trade for a slightly more concise syntax, especially since it would make Gleam more visually unusual which could hinder adoption.

[michallepicki]

Is f(1, 2) a call to a function that takes 2 arguments, or is it a call to a function that takes one argument that is a tuple? In OCaml there is no difference

I think this is not accurate, see the bottom of this section of the real world ocaml book. But that is the case in Standard ML I think

[lpil]

I could be wrong, but I seem to recall that currying is optimised away in OCaml where possible, so while conceptually that's how it works, non partial calls and tuple arguments compile to the same code.