If you really need anonymous tuple types that support decoding that sort of JSON, it isn't too hard to write one: https://go.dev/play/p/Fn_wUXh2drs
Go's generics don't support varargs types (...yet? who knows) so there'd be a little copypasta if you needed many different tuple lengths, but Java has been doing that for years ;) (IMO, using these anonymous tuple types across a whole codebase is not great: data should be labeled with useful names as it is passed around a program. But if you really are just using this to make json parsing code easier, that seems reasonable to me.) On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com wrote: > Hi there, sorry for weighting in so late in the game, but I just started > again to learn Go and was thinking why the language still doesn't have a > tuple type. > > Now, imagine this scenario: I have a web application which has to access a > webservice that responds with JSON payloads; These payloads are a list of > values, where each value is a smaller list like '[20220101, 1.234, "New > York"]'. And these smaller lists follow the same type sequence: int64, > float64, string. Suppose that I want to filter those values and send a > response to the client, with the data structure unchanged (same format and > types). Today, it doesn't seem to be possible to do that in Go, unless I do > some dirty hack like decoding to '[]any' and then cast to the other types, > and then hack again to put these values in the response to the client. > > I totally understand the reasoning for preferring the usage of structs for > heterogeneous data (and I myself do prefer them, they're much more powerful > in general), but there's real world data that's available like in the > example above, and we just can't go on changing them at their sources. I > might be mistaken (please let me know if it's the case), but it seems like > Go is missing an opportunity to interoperate with what's a fundamental data > structure in many other languages (Python, Rust etc). I'm having a lot of > fun learning to use the language, and would be happy to see this feature > being implemented at the core. > > (Maybe what I said above is total BS, I acknowledge that since I'm an > almost complete ignorant in the language) > > Cheers! > > On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote: > >> Multiple return values. They do kinda exist in a declarative form of >> sorts, in the type signature, this sets the number and sequence and types >> of return values. You could even make functions accept them as also input >> values, I think, but I don't think it works exactly like this. I'm not a >> fan of these things because of how you have to nominate variables or _ and >> type inference will make these new variables, if you := into whatever the >> return was. >> >> I'm not sure what the correct word is for them. Untyped in the same way >> that literals can be multiple types (especially integers) but singular in >> their literal form. >> >> >> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote: >>> >>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <louki.sumir...@gmail.com> >>> wrote: >>> >>> > Sorry for the self-promotion but it was relevant in that I was working >>> on how to tidy up the readability of my code and needed multiple returns >>> and simple untyped tuples were really not nearly as convenient as using a >>> type struct. >>> >>> I have no idea what you mean by 'untyped tuples' because Go does not >>> have tuples, or at least not as a well defined thing. I can only guess if >>> you're trying to implement tuples in Go with an array, slice or a struct, >>> ...? To add to my confusion, Go functions can have as many return values as >>> one wishes just fine, ie. I obviously do not even understand what problem >>> you're trying to solve. Sorry. >>> >>> >>> -- >>> >>> -j >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a44eddb7-55d5-4203-a0bc-393b6ec31baan%40googlegroups.com.
