On Fri, Sep 4, 2020 at 2:57 PM aind...@gmail.com <aindu...@gmail.com> wrote: > > I agree that this functionality can be implemented outside the standard > library. However, traversing nested data structures does seem to fall into > reflect's domain. In particular, one would have to deal with unexported > fields and pointer cycles. > > I can also see how a newcomer would think the standard library would be able > to print any value in the language. > > > there will inevitably be a lot of desire for customization of the printed > > output, which will lead to a complex API. > > This is a fair. Maybe the goal should be to provide a general mechanism to > walk data structures, rather than format them?
Well, that too can live outside of the reflect package. Probably the right approach would be write a third party package, see whether it seems popular, and then consider whether to bring it into the standard library. You suggest that traversing nested data structure is reflect's domain, but I'm not sure I agree. The only current case is reflect.DeepEqual. Ian > On Friday, September 4, 2020 at 4:24:23 PM UTC-4 Ian Lance Taylor wrote: >> >> On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com <aind...@gmail.com> wrote: >> > >> > Often on my team, Go programmers (particularly new ones) simply want full >> > visibility into a data structure when debugging. For those who aren't >> > familiar with pointers, seeing a hexadecimal number show up in a log can >> > be really frustrating. I usually point them to >> > https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. >> > Although they can be heavy-handed with their unsafe package dependency and >> > fancy formatting, they are indispensable when debugging data structures >> > like syntax trees. >> > >> > I wonder it's worthwhile to add this functionality to the reflect package, >> > and take advantage of the functionality that DeepEquals uses. I'm not a >> > fan of Dump functions that just take an io.Writer. Why not add a named >> > type for interface{} or reflect.Value called reflect.Deep, which >> > implements fmt.Formatter? Then, packages that use fmt will have more >> > precise control over formatting, and we can maybe add special formatting >> > directives for reflect.Deep. >> > >> > What do you think? >> >> Well, we already have fmt.Printf("%#v", value). >> >> I don't see any obvious reason to add printing to the reflect package. >> It doesn't require any internal information, and can be written >> entirely separately. And, there will inevitably be a lot of desire >> for customization of the printed output, which will lead to a complex >> API. >> >> Basically: https://golang.org/doc/faq#x_in_std . >> >> Ian > > -- > 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/beda96b2-9f41-41f8-a501-3090b15ed37bn%40googlegroups.com. -- 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/CAOyqgcUNK2jn0q%2B3xttWuyBDDxEtAKJ0%2BMOc4LMn5apScgmQcQ%40mail.gmail.com.
