【问题标题】:Composite literal and fields from an embedded type来自嵌入类型的复合文字和字段
【发布时间】:2015-04-30 22:45:56
【问题描述】:

我正在编写一个示例程序来回答关于 SO 的另一个问题,但发现自己对以下代码无法编译的事实感到有些困惑;

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()
}

错误是;

/tmp/sandbox596198095/main.go:28: unknown B field 'FName' in struct literal
/tmp/sandbox596198095/main.go:28: unknown B field 'LName' in struct literal

是否可以在静态初始化程序中设置嵌入类型的字段值?如何?对我来说,这似乎是一个编译器错误;如果我面前没有资源并且熟悉类型,我会用头撞墙说“显然 FName 存在于 B 上,编译器在说什么!?!?!”。

很快,为了抢占典型答案,我知道最接近的工作语法是 b := &B{A{FName:"evan", LName:"mcdonnal"}},但我认为该语法在概念上与嵌入相矛盾,所以如果它是唯一的选择,我会感到失望。如果这是唯一的方法,是 Go 编译器的缺点还是实际上存在理论上的限制,会阻止编译器解释我的非工作示例中的语法?

【问题讨论】:

标签: go embedding composite-literals


【解决方案1】:

这不是编译器错误,而是设计决策。语言规范只是声明:

提升字段的作用类似于结构的普通字段,但它们不能用作结构的复合文字中的字段名称。

我猜这背后的原因是为了避免歧义。使用选择器时有一些解决名称冲突的规则,它们必须很复杂才能允许您的建议。最重要的是,如果您在嵌入类型的结构文字内使用嵌入结构的现有实例,则可能会产生歧义。

编辑:这是一个这种方法可能适得其反的例子:

想一想你有 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 }  ?

它打破了初始化顺序在具有字段名称的复合文字中不相关的假设。

【讨论】:

  • 从规范中引用 :)。但我不相信你的猜测原因。我认为支持b := B{FName:"x", "LName:"y"} 与支持b := B{}; b.FName="x"; b.LName="y" 相比没有太大区别。
  • 是的,这句话清楚地表明我的代码无法编译。不过我同意@DaveC……如果这是一个有意识的设计决定,那就错了。 Dave 的评论指出了我在设计上的主要问题。一方面,我毫无怨言地访问了该字段,另一方面,编译器声称它在该结构中不存在。这从根本上说是矛盾的。
  • @Not_a_Golfer,很好的补充/编辑。编译器以任何感觉的顺序在复合文字中进行分配应该没有问题是有道理的。另一方面,必须明确说出B.X=2; B.A=a B.A=a; B.X=2 才能明确/清晰。
猜你喜欢
  • 2018-09-02
  • 2018-05-21
  • 2018-03-09
  • 2019-02-22
  • 1970-01-01
  • 2016-09-08
  • 2014-12-31
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多