Go 2.0 该如何满足开发者的期待?( 二 )

range的改进:不要复制值
虽然文档很齐全 , 但 range 子句中的值被复制还是出人意料 。 例如 , 考虑以下代码:

type Foo struct {bar string}
func main {list :=[]Foo{{"A"}, {"B"}, {"C"}}
cp := make([]*Foo,len(list))for i, value := rangelist {cp[i] = &value}
fmt.Printf("list:%q\n", list)fmt.Printf("cp:%q\n", cp)}
cp的值是什么?[A B C] ?不好意思 , 你错了 。 实际上 , cp 的值为:
[C C C]
这是因为 Go 的 range 子句中使用的是值的副本 , 而不是值本身 。 在 Go 2.0 中 , range 子句应该通过引用传递值 。 此外 , 我还有一些关于 Go 2.0 的建议 , 包括改进 for-loop , 在每次迭代中重新定义范围循环变量 。
确定的 select
在 select 语句中 , 如果有多个条件为真 , 那么究竟会执行哪个语句是不确定的 。 这个细微的差异会导致错误 , 这个问题与使用方法相似的switch语句相比更为明显 , 因为 switch 语句会按照写入的顺序逐个求值 。
考虑以下代码 , 我们希望的行为是:如果系统停止 , 则什么也不做 。 否则等待 5 秒 , 然后超时 。
for {select {case <-doneCh: // or<-ctx.Done:returncase thing :=<-thingCh:// ... long-runningoperationcase<-time.After(5*time.Second):returnfmt.Errorf("timeout")}}
对于 select 语句 , 如果多个条件为真(例如 doneCh 已关闭且已超过 5 秒) , 则最后会执行哪个语句是不确定的行为 。 因此 , 我们不得不加上冗长的取消代码:
for {// Check here in casewe've been CPU throttled for an extended time, we need to// check graceful stopor risk returning a timeout error.select {case <-doneCh:returndefault:}
select {case <-doneCh:returncase thing :=<-thingCh:// Even though thiscase won, we still might ALSO be stopped.select {case <-doneCh:returndefault:}// ...default<-time.After(5*time.Second):// Even though thiscase won, we still might ALSO be stopped.select {case <-doneCh:returndefault:}return fmt.Errorf("timeout")}}
如果能够将 select 语句改成确定的 , 则原始代码(更简单且更容易编写)就可以按预期工作 。 但是 , 由于 select 的非确定性 , 我们必须不断检查占主导地位的条件 。
此外 , 我希望看到“如果该分支通过条件判断 , 就执行下面的代码 , 否则继续下一个分支”的简写语法 。 当前的语法很冗长:
select {case <-doneCh:returndefault:}
我很想看到更简洁的检查 , 比如像下面这样:
select<-?doneCh: // notvalid Go 结构化日志接口
Go的标准库包含 log 包 , 可用于处理基本操作 。 但是 , 大多数生产系统都需要结构化的日志记录 , 而 Go 中也不乏结构化日志记录库:
● apex/log
● go-kit/log
● golang/glog
● hashicorp/go-hclog
● inconshreveable/log15
● rs/zerolog
● sirupus/logrus
● uber/zap
由于 Go 在这个领域没有给出明确的意见 , 因此导致了这些包的泛滥 , 其中大多数都拥有不兼容的功能和签名 。 因此 , 库作者不可能发出结构化日志 。 例如 , 我希望能够在 go-retry、go-envconfig 或 go-githubactions 中发出结构化日志 , 但这样做就会与其中某个库紧密耦合 。 理想情况下 , 我希望库的用户可以自行选择结构化日志记录解决方案 , 但是由于缺乏通用接口 , 使得这种选择非常困难 。

特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。