How do I initialise a doubly/deeply nested struct?

[uvic...@gmail.com]

I know how to initialise this:

type foo struct {

bar struct {

value int

}

}

http://play.golang.org/p/WrYc_jUrwz

How would I initialise this:

type tar struct {

foo struct {

bar struct {

value int

}

}

}

http://play.golang.org/p/kZwYniUD-L

I have deeply nested structs as a result of JSON decoding but would like to also create them manually for testing purposes.

[Ian Lance Taylor]

There is unfortunately no really useful way to write a composite
literal for that kind of type. Easier to initialize it field by
field. Both versions shown here:

http://play.golang.org/p/m2pMJWrIgR

Ian

[Dan Dubois]

Thanks!

[Matt Harden]

Another option is to name the inner structs as well, which makes it more succinct.

http://play.golang.org/p/q2BRCpor5Y

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matt Harden]

Oh, and then you can shorten the initialization to this.

f := &tar{foo{bar{2}}}

Which is not too shabby.

[Matt Harden]

Does anyone know why Go can't or doesn't infer the type of the initializer on struct fields with a definite type?

[Ian Lance Taylor]

On Fri, Nov 22, 2013 at 4:55 PM, Matt Harden <matt....@gmail.com> wrote:
> Does anyone know why Go can't or doesn't infer the type of the initializer
> on struct fields with a definite type?

We tried it, and tried turning it on whereever possible, and it made
complex struct composite literals unreadable.

It's doable if someone wants to make a reasoned argument, but that
argument has to include actually showing the changes on real code.

Ian

[Matt Harden]

But just having the ability to infer the type doesn't force the developer to use it. In the case of structs that contain several levels of anonymous structs, an initializer is currently forced to be very repetitive. For the OP's example, which wasn't that complex, here's what you end up with for a shortest possible initializer:

x := &tar{struct{bar struct{value int}}{struct{value int}{2}}}

Notice the unavoidable repetition of struct{value int}. This gets exponentially worse with as the complexity of anonymous structs grows. For example if the tar type were anonymous as well, we would have this:

x := &struct{foo struct{bar struct{value int}}}{struct{bar struct{value int}}{struct{value int}{2}}}

where we have to repeat bar twice and value three times.

Adding just one field to foo makes it look like this:

x := &struct{foo struct{bar struct{value int}}, baz struct{value string}}}}{struct{bar struct{value int}, baz struct{value string}}{struct{value int}{2}, struct{value string}{"abc"}}}}

I think you can see what I mean by exponentially worse.

If type inference applied, this would be possible (for the original example):

x := &tar{foo: {bar: {value: 2}}}

which to me is much more readable. Yes, it could be shortened further to &tar{{{2}}}, which is arguably less clear, but again the programmer is not forced to use this super-short style, whereas they are currently forced to state and re-state the anonymous struct types, which to me is much less readable.

I realize the example is not "real code", but large hierarchies of anonymous structs can be useful in JSON or XML encoding and decoding. Building tests with hardcoded sample data of those types is currently too onerous. Applying type inference would fix that, without breaking any working code.

[tjholo...@gmail.com]

I have no real comment other than +1 :D 

[xingtao zhao]

+1