3 ms·

> Go doesn't have tuples because they aren't very compatible with compile-time type safety. What's the problem? Couldn't you have something like: (string,

by Dewie 12y ago

> Go doesn't have tuples because they aren't very compatible with compile-time type safety. What's the problem? Couldn't you have something like: (string, int) For example in the return type of a function? I.e., this function returns a tuple of string and int.

NateDad 12y ago
What's the difference between that and multiple returns? You can have func foo() (string, int) func bar(a string, b int) And do bar(foo()) The only thing you couldn't do is make a slice of tuples... But you can make a slice of structs that have just a string and an int. I guess I just don't see a huge amount of utility that isn't otherwise already covered.
- Dewie 12y ago
  > What's the difference between that and multiple returns? It's a more general concept than multiple returns. Why special-case something, needlessly?
  - NateDad 12y ago
    A tuple appears to be a special case of a struct. Not sure why you need (int, bool) when you can have struct{i int, b bool}... the tuple you have to access via index, and the struct you access via name... and by name is much more clear in your code.
    - Dewie 12y ago
      > Not sure why you need (int, bool) when you can have struct{i int, b bool}... You tell me: you for some reason do need (or want) multiple returns. Why, when you can just use a struct? ;) > the tuple you have to access via index, and the struct you access via name... and by name is much more clear in your code. I guess Go doesn't have destructing (like - `(x, y) := some_fun()`). In that case, I can see how it could be more annoying than the multiple return thing. I do not see, however, how tuples necessitate indexing - in the languages I've used with tuples, the arity is known at compile time, and you have to use certain functions to access the first, second, etc. But if the choice is between multiple returns (which I guess is just two values?) and tuples, then I don't see why the common case (2-arity) can't be easily supported.

by Dewie 12y ago

NateDad 12y ago

What's the difference between that and multiple returns? You can have func foo() (string, int) func bar(a string, b int) And do bar(foo()) The only thing you couldn't do is make a slice of tuples... But you can make a slice of structs that have just a string and an int. I guess I just don't see a huge amount of utility that isn't otherwise already covered.

Dewie 12y ago
> What's the difference between that and multiple returns? It's a more general concept than multiple returns. Why special-case something, needlessly?
- NateDad 12y ago
  A tuple appears to be a special case of a struct. Not sure why you need (int, bool) when you can have struct{i int, b bool}... the tuple you have to access via index, and the struct you access via name... and by name is much more clear in your code.
  - Dewie 12y ago
    > Not sure why you need (int, bool) when you can have struct{i int, b bool}... You tell me: you for some reason do need (or want) multiple returns. Why, when you can just use a struct? ;) > the tuple you have to access via index, and the struct you access via name... and by name is much more clear in your code. I guess Go doesn't have destructing (like - `(x, y) := some_fun()`). In that case, I can see how it could be more annoying than the multiple return thing. I do not see, however, how tuples necessitate indexing - in the languages I've used with tuples, the arity is known at compile time, and you have to use certain functions to access the first, second, etc. But if the choice is between multiple returns (which I guess is just two values?) and tuples, then I don't see why the common case (2-arity) can't be easily supported.