That was perfectly put, Daniel, thanks! :-) And, indeed, what I've been doing is to unmarshal as a "[][]any" and then coercing to the right types.
I also agree tuples have a place in the world. They're quite common when dealing with tabular data - for example, to reduce the amount of repetition when describing "rows" of data. But I don't really have to agree or disagree - they just exist, and that itself begs for an action: either ignore them, or find a workaround (like https://github.com/barweiss/go-tuple ), or implement the syntax, type etc for it (which I totally understand if it's too hard or undesirable). Some approaches that I find interesting are Python's type hints (e.g. "tuple[int, float, str]", which is well checked with tools like mypy) or even the cleaner approach from Rust (e.g. "(i32, f64, String)"). But anyway, I digress. I like the approach with struct tags too; While not being a real implementation of tuples, they at least help with unmarshalling and marshalling of data to cope with other existing services when they need to follow that structure. Cheers! On Tuesday, December 6, 2022 at 7:27:38 PM UTC-3 dple...@google.com wrote: > On Sat, Dec 3, 2022 at 11:34 PM burak serdar <bse...@computer.org> wrote: > >> >> >> On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder <diogo...@gmail.com> wrote: >> >>> 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. >>> >> >> What you described above is a struct. >> > > I think the problem Diogo is pointing out is a reasonable one - you > specify the type of the object you're unpacking by e.g. > json.Unmarshal(data, &typedObject), but right now there's no way (AFAIK) > for the typed object to capture "a list of [int, float, string] triples" > except by capturing it as a [][]any and then manually typechecking that > each one is indeed an int, a float, and a string. > > It'd be great if, for example, you could tag an entire type like: > > type Row struct { `json:tuple` > date int64 > score float64 > city string > } > > so that > > var v []Row > json.Unmarshal(data, &v) > > would automatically parse the triples into usable structs (and > json.Marshal would turn them back into lists). > > ***** > > I also don't think arguments that Go doesn't need tuples really hold > water, given that Go already *has* tuples, just only for return types. We > could all be writing > > func Foo() struct{int, error} { > return struct{int, error}{3, nil} > } > v := Foo() > i, err := v.int, v.error > ... > > but I think everyone agrees that tuples make this code much more readable. > Given that we all do agree that there are cases where having tuples makes > for better code, I don't actually know why Go doesn't support them in > general. Is it out of fear that people will use them poorly, or is it > actually pretty complex to implement and not worthwhile? > > -- > Dan Lepage > -- 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/64d5942a-1723-4578-84f0-d7d3083b1947n%40googlegroups.com.
