You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the frustrating points for newcomers to Go is the syntax for declaring nested structs. Especially considering other languages make it concise and easily memorable.
Right now that syntax for declaring it in one go looks like this:
typeBstruct {
Namestring`json:"name"`Descriptionstring`json:"description"`Tagsstring`json:"tags"`
}
typeAstruct {
BB`json:"b"`
}
// Syntax for declaring instances of A or Bb:=B{
Name: "somename",
}
a:=&A{
B: B{
Name: "somename",
Description: "abc",
},
}
And I've noticed a few times that intuitively, people tend to keep the struct A declaration nested, and try to guess the syntax for declaring one instance of it.
That syntax is the following, and it's pretty complicated (again I'm comparing to other scripting languages that provide no type safety at all, it's a pretty unfair comparison):
typeAstruct {
Bstruct {
Namestring`json:"name"`Descriptionstring`json:"description"`Tagsstring`json:"tags"`
} `json:"b"`
}
// Syntax for declaring an instance of A// notice it's impossible to declare an instance of B, it not being a type by itselfa:=&A{
B: struct {
Namestring`json:"name"`Descriptionstring`json:"description"`Tagsstring`json:"tags"`
}{
Name: "somename",
Description: "abc",
},
}
Which leads to my syntax proposal for doing the same thing:
// even while keeping the type declaration nestedtypeAstruct {
Bstruct {
Namestring`json:"name"`Descriptionstring`json:"description"`Tagsstring`json:"tags"`
} `json:"b"`
}
// A.B would automatically be accessible as a type itselfb:= A.B{
Name: "somename",
}
// creating an A would be more concise without losing any clarity about typesa:=&A{
B: A.B{
Name: "somename",
Description: "abc",
},
}
What is your opinion about this syntax ?
I'm not familiar with the go codebase yet, but I'd be happy to start looking into it, I just wish to see how the go community would receive such a change first.
Also, are there strong reasons (that I don't see) to not introduce that change ?
The text was updated successfully, but these errors were encountered:
bcmills
changed the title
Syntax proposal for declaring nested structs in Go
proposal: spec: syntax for declaring nested structs
Jun 12, 2018
@bcmills that's a valid point, thanks for pointing to the other issue.
I'm not sure if the elision would always be clearer, but it's certainly more concise, and there's always the possibility of specifying types if any code gets unclear, so I'd be happy with the solution you pointed out !
I also like the idea of making sub-types accessible without breaking the nesting visually though.
I don't like this, mainly because now A.B becomes ambiguous. It's not intuitive to me to have A.B sometimes be a value, and sometimes be a type. This would also definitely complicate the Go spec since there is no other case when something like this occurs.
As @bcmills says, #21496 seems easier to understand, and as @deanveloper says, using the same name as both a type and a value has the potential to be quite confusing. We aren't going to make this change, but thanks for the suggestion.
One of the frustrating points for newcomers to Go is the syntax for declaring nested structs. Especially considering other languages make it concise and easily memorable.
Right now that syntax for declaring it in one go looks like this:
And I've noticed a few times that intuitively, people tend to keep the struct A declaration nested, and try to guess the syntax for declaring one instance of it.
That syntax is the following, and it's pretty complicated (again I'm comparing to other scripting languages that provide no type safety at all, it's a pretty unfair comparison):
Which leads to my syntax proposal for doing the same thing:
What is your opinion about this syntax ?
I'm not familiar with the go codebase yet, but I'd be happy to start looking into it, I just wish to see how the go community would receive such a change first.
Also, are there strong reasons (that I don't see) to not introduce that change ?
The text was updated successfully, but these errors were encountered: