I might be missing something, but you can just iterate over your list of structs and delete/set-to-default-value the offending field before shipping it to your client. Same as tuples afaic.
On Monday, December 5, 2022 at 8:39:17 PM UTC-7 diogo...@gmail.com wrote: > Hi folks, > > Thanks for all the inputs, I really appreciate the effort and help :-) > > Regardless of the whole discussion of whether or not tuples are a good or > bad data structure, they exist out there in the wild, and we have to deal > with them in many situations - of course, in our own code we can opt by > continuing to use them or not, depending on the language we're using. It > would be nice if Go could support them as first-class citizens - I know > it's not the only language that doesn't, though, Java for example doesn't > support them either (BTW there's a nice Java library, javatuples, which > gives nice names like Pair, Triplet, Quartet etc, to n-sized "tuples" - I > find that enjoyable). > > Anyways, thanks for the discussion, that helps me get a better grasp of > the language! > > Cheers! > > On Sunday, December 4, 2022 at 11:39:41 PM UTC-3 Kevin Chowski wrote: > >> 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/c10afa0a-07c9-4363-a304-e6a4602719fcn%40googlegroups.com.
