复合文字和嵌入式字段 [英] Composite literal and fields from an embedded type
问题描述
我正在编写一个示例程序来回答这里的另一个问题，并发现自己对以下代码无法编译的事实感到有些困惑;
https://play.golang.org/ p / wxBGcgfs1o
包主
$ b导入fmt
type A struct {
FName string
LName string
}
type B struct {
A
}
func（a * A）Print（）{
fmt.Println（a.GetName（））
}
func（a * A）GetName（） string {
return a.FName
}
func（b * B）GetName（）string {
return b.LName
}
func main（）{
a：=& A {FName：evan，LName：mcdonnal}
b：=& B {FName：evan，LName： mcdonnal}
a.Print（）
b.Print（）
}
错误是;
/tmp/sandbox596198095/main.go:28：unknown B结构体字段中的'FName'
/tmp/sandbox596198095/main.go:28：结构字面量中的未知B字段'LName'
可能吗？ le在静态初始化器中设置嵌入类型的字段值？怎么样？对我来说，这似乎是一个编译器错误;如果我没有在我面前的来源，并熟悉类型我会打我的头靠在墙上说：明确F名存在于B什么是编译器说！！？！。
很快，为了抢占典型的答案，我知道最接近的工作语法是 b：=& B {A {FName：evan，LName： mcdonnal}} 但在我看来，这种语法在概念上与嵌入相矛盾，所以如果它是唯一的选择，我会感到失望。如果这是唯一的方法，它是Go编译器的一个简短的介绍，还是实际上存在一个理论上的限制，它会阻止编译器在我的非工作示例中解释语法？
它不是一个编译器 bug ，而是一个设计决定。语言规范只是指出：
升级字段的作用类似于普通字段的结构，除了它们不能用作复合字面值中的字段名结构。
我猜这背后的原因是为了避免含糊不清。在使用选择器时，有几条规则可以解决名称冲突，为了允许您提出的建议，它们必须很复杂。最重要的是，如果您在嵌入类型的结构字面值中使用嵌入式结构的现有实例，则可能会产生歧义。
编辑：这里有一个例子，这种方法可能会适得其反：
想想你有A嵌入B，以及要嵌入的A的实例：
type A {
X int
}
type B {
A
}
这很容易做到：
b：= B {X：1}
并推断应该做什么。
但是如果我们已经有一个A的实例呢？这是没有道理的：
a：= A {X：1}
b：= B {X：2，A：a，}
您是否首先将2分配给A然后将A的初始化实例分配给它？这是相同的：
b：= B {A：a，X：2}？
它打破了假设：初始化顺序在带有字段名称的复合文本中无关紧要。
I was working on a sample program to answer another question here on SO and found myself somewhat baffled by the fact that the following code will not compile;
https://play.golang.org/p/wxBGcgfs1o
package main
import "fmt"
type A struct {
FName string
LName string
}
type B struct {
A
}
func (a *A) Print() {
fmt.Println(a.GetName())
}
func (a *A) GetName() string {
return a.FName
}
func (b *B) GetName() string {
return b.LName
}
func main() {
a := &A{FName:"evan", LName:"mcdonnal"}
b := &B{FName:"evan", LName:"mcdonnal"}
a.Print()
b.Print()
}
The error is;
/tmp/sandbox596198095/main.go:28: unknown B field 'FName' in struct literal
/tmp/sandbox596198095/main.go:28: unknown B field 'LName' in struct literal
Is it possible to set the value of fields from an embedded type in a static initializer? How? To me this seems like a compiler bug; if I didn't have the sources in front of me and was familiar with type I would be beating my head against a wall saying "clearly FName exists on B what is the compiler saying!?!?!".
Quickly, to preempt typical answers I am aware that the closest working syntax is this b := &B{A{FName:"evan", LName:"mcdonnal"}} but that syntax is in my opinion conceptually contradictory to embedding so I would be disappointed if it is the only option. If this is the only way, is it a short coming of the Go compiler or is there actually a theoretical limitation that would prevent a compiler from interpreting the syntax in my non-working example?
It's not a compiler bug but a design decision. The language spec just states:
Promoted fields act like ordinary fields of a struct except that they cannot be used as field names in composite literals of the struct.
I guess the reasoning behind this is to avoid ambiguity. There are a few rules to resolve name conflicts when using selectors, and they would have to be complicated in order to allow what you're suggesting. On top of that, it might create ambiguity if you're using an existing instance of an embedded struct inside a struct literal of the embedding type.
EDIT: Here's an example where this approach might backfire:
Think of a case where you have A embedding B, and an instance of A you want to embed:
type A {
X int
}
type B {
A
}
It's simple enough to do
b := B{ X: 1 }
And infer what should be done. But what if we already have an instance of A? This doesn't make sense:
a := A { X: 1 }
b := B { X: 2, A: a, }
are you first assigning 2 to a zero instance of A and then assigning the initialized instance of A over it? And is it identical to:
b := B { A: a, X: 2 } ?
It breaks the assumption that initialization order is irrelevant in a composite literal with field names.
这篇关于复合文字和嵌入式字段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
