Can I convert a []T to an []interface{}?
我可以将 []T 转换为 []interface{} 吗?
Not directly. It is disallowed by the language specification because the two types do not have the same representation in memory. It is necessary to copy the elements individually to the destination slice. This example converts a slice of int
to a slice of interface{}
:
不允许直接转。语言规范不允许这样做,因为这两种类型在内存中没有相同的表示形式。需要将元素单独复制到目标切片。
下面示例将 int切片 转换为interface{}切片 :
individually
adv. 分别地;各个地;各自地;独特地;
t := []int{1, 2, 3, 4}
s := make([]interface{}, len(t))
for i, v := range t {
s[i] = v
}
Can I convert []T1 to []T2 if T1 and T2 have the same underlying type?
如果 T1 和 T2 具有相同的基础类型,我可以将 []T1 转换为 []T2 吗?
This last line of this code sample does not compile.
该代码示例的最后一行无法编译。
type T1 int
type T2 int
var t1 T1
var x = T2(t1) // OK
var st1 []T1
var sx = ([]T2)(st1) // 编译不过
In Go, types are closely tied to methods, in that every named type has a (possibly empty) method set. The general rule is that you can change the name of the type being converted (and thus possibly change its method set) but you can't change the name (and method set) of elements of a composite type. Go requires you to be explicit about type conversions.
在 Go 中,类型与方法紧密相关,因为每个命名类型都有一个(可能为空)方法集。一般规则是,您可以更改要转换的类型的名称(因此可能更改其方法集),但不能更改复合类型元素的名称(和方法集)。Go 要求您明确类型转换。
Why is my nil error value not equal to nil?
为什么我的 nil 错误值不等于 nil?
Under the covers, interfaces are implemented as two elements, a type T
and a value V
. V
is a concrete value such as an int
, struct
or pointer, never an interface itself, and has type T
. For instance, if we store the int
value 3 in an interface, the resulting interface value has, schematically, (T=int
, V=3
). The value V
is also known as the interface's dynamic value, since a given interface variable might hold different values V
(and corresponding types T
) during the execution of the program.
在幕后,接口被实现为两个元素:类型T 和值V。 V是一个具体值,例如int、 struct或指针,而不是接口本身,并且具有类型T。例如,如果我们将int值 3 存储在接口中,则结果接口值示意性地为 ( T=int, V=3)。该值V也称为接口的 动态值,因为给定的接口变量在程序执行期间 可能保存不同的值V (以及相应的类型)。T
schematically
adv. 计划性地,按照图式;
An interface value is nil
only if the V
and T
are both unset, (T=nil
, V
is not set), In particular, a nil
interface will always hold a nil
type. If we store a nil
pointer of type *int
inside an interface value, the inner type will be *int
regardless of the value of the pointer: (T=*int
, V=nil
). Such an interface value will therefore be non-nil
even when the pointer value V
inside is nil
.
当V
跟T
均未设值(T=nil、V未设置)时,接口的值是nil,特别是,nil接口将始终保存nil类型。如果我们将int类型的nil存储在接口的值 V
,则内部的类型 T
将int与指针的值无关:( T=*int, V=nil)。 因此,即使内部指针值V
为nil ,这样的接口值也不是 nil。
This situation can be confusing, and arises when a nil
value is stored inside an interface value such as an error
return:
这种情况可能会令人困惑,当nil值存储在接口值(例如error返回值)内时,就会出现这种情况:
func returnsError() error {
var p *MyError = nil
if bad() {
p = ErrBad
}
return p // Will always return a non-nil error.
}
If all goes well, the function returns a nil
p
, so the return value is an error
interface value holding (T=*MyError
, V=nil
). This means that if the caller compares the returned error to nil
, it will always look as if there was an error even if nothing bad happened. To return a proper nil
error
to the caller, the function must return an explicit nil
:
如果一切顺利,该函数将返回 p值为 nil ,因此返回值是一个持有 error接口值( T=*MyError
, V=nil
)。这意味着如果调用者将返回的错误与nil进行比较,它看起来好像总是存在错误即使没有发生任何不好的事情。要向调用者返回适合的 nil
error
值,该函数必须返回一个显式的nil:
func returnsError() error {
if bad() {
return ErrBad
}
return nil
}
It's a good idea for functions that return errors always to use the error
type in their signature (as we did above) rather than a concrete type such as *MyError
, to help guarantee the error is created correctly. As an example, os.Open
returns an error
even though, if not nil
, it's always of concrete type *os.PathError
.
对于返回错误的函数来说,最好始终使用error
其签名中的类型(如我们上面所做的那样)而不是具体类型(例如 )*MyError
,为了确保正确创建错误。例如, os.Open
返回一个error
,虽然如果不是nil
,它始终是具体类型 *os.PathError
。
Similar situations to those described here can arise whenever interfaces are used. Just keep in mind that if any concrete value has been stored in the interface, the interface will not be nil
. For more information, see The Laws of Reflection.
每当使用接口时,都会出现与此处描述的类似情况。请记住,如果接口中存储了任何具体值,则该接口将不为nil
。有关更多信息,请参阅 反射定律。
Why are there no untagged unions, as in C?
为什么没有像 C 中那样的未标记联合?
untagged
未加标签的;
Untagged unions would violate Go's memory safety guarantees.
未标记的联合会违反 Go 的内存安全保证。