This is a significant language change, so marking as Go2.

Personally I think this change is unlikely to be adopted. Note that although C permits a struct to be defined within another struct, the struct tags are all at top level. There is no nesting of names, which seems to be your concern. As far as I can see the only effect of nesting of names in Go would be to permit writing X.Y instead of XY. That seems like a minor benefit. And your example is about code generation; it is trivial for a code generator to generate long names, so even the benefit seems even less important in that few people will ever type that long name.

Thanks for your reply, @ianlancetaylor. I agree that it is trivial for code generators to generate the long names. But in our case, these generated APIs are ultimately consumed by developers. It would make it a bit cumbersome for such users to use the APIs with long names.

@abhikeshav But just to clarify, we are talking about the difference between writing Employee.EmploymentData and writing EmployeeEmploymentData, right?

@ianlancetaylor Exactly.

To give a different example, if there are slices inside a struct like the below,

type Employee struct {
    employee_id string
    hello []EmployeeEmploymentDataInsideADeeplyNestedStructForExampleHello
    bye []EmployeeEmploymentDataInsideADeeplyNestedStructForExampleBye
}

type EmployeeEmploymentDataInsideADeeplyNestedStructForExampleHello struct {
      date_of_joining string
}

type EmployeeEmploymentDataInsideADeeplyNestedStructForExampleBye struct {
      date_of_joining string
}

users of this Go API will have to instantiate the inner objects and append them like below:

bob := Employee{employee_id:"1234"}

data1 := EmployeeEmploymentDataInsideADeeplyNestedStructForExampleHello{"12-12-2010"} // this is cumbersome since the name is super-long
data2 := EmployeeEmploymentDataInsideADeeplyNestedStructForExampleBye{"13-10-2012"}

bob.hello = append(bob.hello, data1)
bob.bye = append(bob.bye, data2)

https://play.golang.org/p/CVDAEaNOR2

The above could be made easier to read if '.' notation was allowed for the types, meaning the types are nested.

bob := Employee{employee_id:"1234"}

// nested types makes it a lot clearer than having a super-long name
data1 := Employee.EmploymentData.Inside.ADeeplyNestedStruct.ForExample.Hello{"12-12-2010"} 
data2 := Employee.EmploymentData.Inside.ADeeplyNestedStruct.ForExample.Bye{"13-10-2012"} 

bob.hello = append(bob.hello, data1)
bob.bye = append(bob.bye, data2)

Won't this have the same effect:

bob := Employee{employee_id:"1234"}

data1 := Employee_EmploymentData_Inside_ADeeplyNestedStruct_ForExample_Hello{"12-12-2010"} 
data2 := Employee_EmploymentData_Inside_ADeeplyNestedStruct_ForExample_Bye{"13-10-2012"} 

bob.hello = append(bob.hello, data1)
bob.bye = append(bob.bye, data2)

It is not the same thing. From a programmatic point of view, having nested types is a better representation of deeply nested yang data models.

As a side note, using underscores actually goes against the golang guidelines :-|

(not that I'm supporting this). As a data point, protocol buffers allow for embedded messages, which get compiled by protoc-gen-go as a struct named GrandParentName_ParentName_ChildName.

@ianlancetaylor, it's not just the difference between writing Employee.EmploymentData and writing EmployeeEmploymentData. The flat approach results in ambiguous output. Employee.Employment.Data, EmployeeEmployment.Data, Employee.EmploymentData and EmployeeEmploymentData would all result in the latter. We can't prevent a hierarchy form having two or more of those patterns. Clearly segmenting nodes in a hierarchy is important.

Furthermore, hierarchies can be 10+ or even 20+ deep. Here's a real life example:

NetworkInstances.NetworkInstance.Protocols.Protocol.Ospfv2.Areas.Area.Lsdb.LsaTypes.LsaType.Lsas.Lsa.OpaqueLsa.ExtendedPrefix.Tlvs.Tlv.SidLabelBinding.Tlvs.Tlv.EroPath.Segments.Segment.UnnumberedHop.State.InterfaceId

versus:

NetworkInstancesNetworkInstanceProtocolsProtocolOspfv2AreasAreaLsdbLsaTypesLsaTypeLsasLsaOpaqueLsaExtendedPrefixTlvsTlvSidLabelBindingTlvsTlvEroPathSegmentsSegmentUnnumberedHopStateInterfaceId

Think of trying to navigate a deep file system with flat paths instead of slash-separated directories. You'd have issues with ambiguity, plus you'd force all paths to be explicitly referenced from the root. You'd want to have the flexibility of relative paths.

It seems that protoc-gen-go could also benefit from this enhancement proposal.

@111pontes, why would a file system be represented as having a nested type for each directory? How would that work? My understanding is that the structure of a filesystem is typically discovered at runtime, but in order to have a type structure like you're suggesting, it would have to be known at compile time. This seems like a odd example to me.

@dsnet, I just used a file system as an analogy of a deeply nested hierarchy everybody is familiar with.

Go in general decomposes concepts rather than nesting them. For instance, methods are not defined inside a type. That was in fact a key point in permitting any type to have a method; nested types as described here would only be permitted within a struct type, which is not very orthogonal.

It seems fine to use an underscore where this proposal would use a dot.

Closing.