3 ms·

> Go has effectively built in option types - multiple returns... They're more like a tuple than an Option type. An Option is a sum type, and a tuple type is a

by Dewie 12y ago

> Go has effectively built in option types - multiple returns... They're more like a tuple than an Option type. An Option is a sum type, and a tuple type is a product type... and Option types are never represented as a product type (like tuple) in languages like Haskell, ML, etc. for a good reason. (Aside: why does Go have multiple returns, instead of just using tuples? Or just use structs? They could even call tuples "anonymous structs" if "tuple" is too academic...) Yes, I guess you meant that they can be used like an Option type, somewhat incidentally and indirectly.

NateDad 12y ago
Go doesn't have tuples because they aren't very compatible with compile-time type safety. You could using []interface{} as a tuple, but why would you? Go does have anonymous structs, they're just only of moderate use in a statically typed language (given that you need to specify the types for function arguments and return types) You can do something like this: // make a list of anonymous structs // often useful for table driven tests tests := []struct{ Name string, count int }{ { Name: "First test", Count: 5 }, { Name: "Second test", Count: 7 } } for _, test := range tests { if test.Count > 5 { t.Errorf("%s: expected <= 5, got %d", test.Name, test.Count) } }
- 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.
- dragonwriter 12y ago
  > Go doesn't have tuples because they aren't very compatible with compile-time type safety. That's...amusing. ML-family languages use tuples extensively (Haskell, because of its preference for currying, somewhat less than others), and yet are light years ahead of Go when it comes to compile-time type safety.
  - NateDad 12y ago
    Sorry, you're right. I was thinking of tuples without defined types for the slots, like "this function returns a tuple of two objects", not "this function returns a tuple of (string, int)".

by Dewie 12y ago

NateDad 12y ago

Go doesn't have tuples because they aren't very compatible with compile-time type safety. You could using []interface{} as a tuple, but why would you? Go does have anonymous structs, they're just only of moderate use in a statically typed language (given that you need to specify the types for function arguments and return types) You can do something like this: // make a list of anonymous structs // often useful for table driven tests tests := []struct{ Name string, count int }{ { Name: "First test", Count: 5 }, { Name: "Second test", Count: 7 } } for _, test := range tests { if test.Count > 5 { t.Errorf("%s: expected <= 5, got %d", test.Name, test.Count) } }

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.
dragonwriter 12y ago
> Go doesn't have tuples because they aren't very compatible with compile-time type safety. That's...amusing. ML-family languages use tuples extensively (Haskell, because of its preference for currying, somewhat less than others), and yet are light years ahead of Go when it comes to compile-time type safety.
- NateDad 12y ago
  Sorry, you're right. I was thinking of tuples without defined types for the slots, like "this function returns a tuple of two objects", not "this function returns a tuple of (string, int)".