5 ms·

Couldn’t you just use a pointer?

• JamesSwift 6y ago
  When I say 'option type' I actually mean the idiomatic go multiple return `(res, err)`. You can define a function to return that but its not actually a first class T, so you cant define a channel that follows the same semantics. That means if you have a bunch of functions that use the `(res, err)` style and you later want to convert them to, e.g., batch processing steps using channels, you have to now add a lot of boilerplate type definitions to tie things together.
  • zem 6y ago
    even more annoyingly, you can define a function that returns it but not a function that accepts it, so you often have to jump through a lot of hoops to combine higher order functions with multiple return values.
    • cle 6y ago
      Not sure what you mean, functions can take multiple return values as arguments just fine: https://play.golang.org/p/l7s7i-QyRnM https://play.golang.org/p/l7s7i-QyRnM
      • JamesSwift 6y ago
        _sort of_. Again, the leaky abstraction comes through when you try to add additional params in addition to the multiple return: https://play.golang.org/p/lwMBkvnaVm0 https://play.golang.org/p/lwMBkvnaVm0
  • cle 6y ago
    Ah got it. Tuples come with their own challenges and are quite similar to structs, so I’m not surprised they didn’t make the cut. I’ve had to define structs like you say occasionally, but it literally takes like 2 seconds so I don’t really care, and appreciate not having to decide when to use tuples vs structs and argue with teammates about it too.
    • JamesSwift 6y ago
      Youre right, it definitely isnt a large amount of work. Its the annoyance of the work and the leaky abstraction of "multiple returns" that _look_ (and sort of act) like its a tuple. In addition to channels, it also comes up if you want to store an array of return values.