| > [...] like saying that passing multiple parameters to C functions is "a tuple". You intended this as a reductio ad absurdum, but you are entirely right. That's how it's handled in eg Haskell. > I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with. Since Go doesn't have a concept of immutable data types (except consts), tuples would effectively be just variable-typed constant-size slices, which are already implementable as arrays of empty interfaces, but have a runtime overhead... I'm not sure that would be a good way to implement tuples. In fact, I suspect it's probably close to the worst way to implement them? I'd image you'd want to take the machinery you have for structs, and adjust it so that it can deal with anonymous structs with anonymous fields identified by position. (But still preserve all the static typing, instead of throwing your hands up and going with 'variable-typed'.) The runtime overhead would be more or less exactly the same as for structs. In general, I see tuples as a syntactic sugar over structs and expect them to be compiled like that (or better) in a statically typed language; instead of representing them as some kind of weird slice. Theoretically, you could probably even implement tuples-via-structs as a preprocessor. > I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with. Yes, so instead of abstaining from tuples, because of these complications, they added a special case for their favourite use case. Have a look at OCaml for a relatively simple language with less design hypocrisy, and fast compile times and fast runtimes. (Compared eg to the much more complex Haskell.) |