Go提案跟踪

留言

proposal: spec: add range over int, range over func #61405


这是一个关于 Golang 的提议（issue #61405），该提议由 rsc 在 Github 上的 Go 语言社区中提出。这个提议主要包括两个部分：

  1. Range Over Integer：这个提议建议在 Golang 中增加对整数进行迭代的能力。如果 n 是一个整数类型，那么 for x := range n { ... } 将等同于 for x := T(0); x < n; x++ { ... }，其中 T 是 n 的类型（假设 x 在循环体内未被修改）。这将使得在很多情况下，编程者无需再使用更复杂的 3-子句 for 循环，可以使用更简洁的 range 循环进行迭代。

  2. Range Over Function：这个提议建议在 Golang 中增加对函数进行迭代的能力。如果 f 是一个形如 func(yield func(T1, T2)bool) bool 的函数类型，那么 for x, y := range f { ... } 将类似于 f(func(x T1, y T2) bool { ... })，其中循环体已被移入到传递给 f 作为 yield 的函数字面量中。这将使得编程者可以在循环中执行用户自定义的迭代逻辑，从而使许多程序得以简化。

这个提议的目的是为了使 Go 语言的迭代操作变得更简单和更直观，同时也使得在编程时，编程者可以更容易地识别出那些可能需要更仔细审查的特殊情况。提议对于整数和函数的迭代都提供了详细的规格说明，并且还提供了一些实例代码以供参考。

目前这个提议仍在讨论阶段，社区成员对这个提议有积极的反馈，但也有一些人对其表示反对或者困惑。


reflect: add TypeFor #60088


https://github.com/golang/go/commit/56d3e84bb0195913e1d932d6fe8251047091076b

https://github.com/golang/go/commit/db25bc19e5221c7df2caed3b1daeda673ec757d9

https://github.com/golang/go/commit/d4b46b0956a6581b62a0534d4eb1d5b5342c3b6f



build: adopt Go 1.20 as bootstrap toolchain for Go 1.22 #54265


https://github.com/golang/go/commit/7141d1e6d820241de321f8a9d336871737560950

这个pr可以再提一次了~

https://go-review.googlesource.com/c/go/+/428920

对于before, after, found := strings.Cut(args, “=”)，有人评论说 This replicates the existing logic, but I think we can make it clearer by writing

1
2
3
4
5
6
before, after, hasEq := strings.Cut(args, "=")
switch verb {
...
    if !hasEq {
        log.Fatalf(...)
    },

该怎么理解？什么意思



cmd/compile: add unrolling stage for automatic loop unrolling #51302


Go团队对编译速度,有近乎偏执的追求,为此愿意放弃和牺牲部分性能提升…

可能最初的痛点是C++编译速度慢,于是才推出Go

但实际上,Go没有取代C++的份额,因为有GC,性能达不到,反倒是事实上在和Java抢夺市场

随着Java的一系列优化,Go如果在性能上,自Go Team不那么重视性能的提升,有一定风险

这块想法,和Andy Pan在Go夜聊的观点差不多

而Rust却是C++的有力竞争者,编译速度很慢,优化得很细致..以带来更快的运行速度

我个人认为，没必要那么纠结编译速度，别慢到令人发指就行。。。要因为编译速度快而用Go，那我为啥不用解释型的语言…




proposal: slices: add a reusable slices.Contains() #66022


我提出的,详情参考 用map还是slice

Ian 给出了评论,并指向了rsc提的另外两个提案, 详见下面两个


这份提案建议优化标准库中的slices.Contains()函数，该函数目前在处理大量元素时时间复杂度较高。提案者建议引入新函数slices.ContainsUseManyTimes()，通过返回一个函数来提高效率，该函数可在处理大量元素时使用二分搜索或哈希映射。性能测试表明，使用二分搜索在大量元素下保持高效，而哈希映射在处理900万个元素时性能下降。最终的代码变更已提交，并附有性能测试结果。



该提案建议在切片包中添加一些新功能，以更好地支持使用迭代器的代码。这是一系列提案之一，旨在更新标准库以适应新的“range over function”功能（＃61405）。这些功能包括All、Backward、Values、Append、Collect、Sorted和SortedFunc等，用于处理切片和迭代器的操作。提案还讨论了是否将某些功能移到独立的迭代器包中，以提高一致性。




该提案旨在向封装映射中添加一些函数，以更好地支持使用迭代器的代码。这是更新标准库的一系列提案之一，用于新的“范围超过函数”功能（#61405）。这些函数包括All、Keys、Values、Insert和Collect，它们分别用作迭代器的“源”和“接收器”。其中，Keys和Values可作为其他迭代适配器的输入，而Insert和Collect用于将键值对从迭代器添加到映射中。有关更多详细信息，请参阅提案讨论。



然后又引入了另外两个提案,其中

spec: add range over int, range over func #61405


该提案已经接受,并且作为Go 1.22的特性之一已经发布

这篇讨论总结提议在Go语言中为for-range语句添加两种新的迭代类型：整数和函数。其中，提到了为支持整数和函数的for-range语句所做的修改，以及在Go playground上使用的方法。对于函数迭代的动机包括支持泛型和标准库中某些函数的需求，使得逐个生成结果的表示形式比返回整个切片更具扩展性。对于整数迭代的动机主要是为了简化常见的计数形式，提高代码的可读性。提议还回答了关于使用接口而非函数迭代、使用库函数进行整数迭代以及更复杂循环实现的常见问题



这个是总提案:

iter: new package for iterators #61897


该提案旨在向标准库添加一个名为iter的新包，定义了在序列上进行迭代的有用类型。这些类型预计将被其他API使用，以表示它们返回可迭代函数。这是对标准库进行更新的一部分，以支持新的“range over function”功能。该提案将仅在该功能被接受时才被接受。此外，还有其他相关提案，如x/exp/xiter、slices、maps、bytes、strings和regexp等。iter包包含Seq和Seq2类型，用于表示迭代器，通过yield函数传递单个值或键值对。对于可能的单次使用迭代器，文档建议在返回这些迭代器的函数或方法中进行说明。最后，提案强调在更新标准库时考虑功能的正确放置，找出iter包可能存在的问题，并为其他人树立一个良好的示例。



然后到了这个讨论

https://github.com/golang/go/discussions/47331


这是一个讨论将转化为提案的内容，旨在与＃43651一起使用。提议定义一个新的包，container/set，引入一种新的集合类型。将其隐藏在结构中的好处之一是允许零值成为可写入的空集，通过按需延迟初始化隐藏字段。这种方法还可以在未来优化集合实现，并确保一致性，避免用户在不同情况下使用不同的语法。这与地图和切片提案的做法相似。最后，通过隐藏映射，使用更清晰、明确和易于理解的方式，提供 iter.Iter 而不提供 iter.Iter2。对于标准库来说，一致性和完善性比直接公开 mapstruct 的简单性更为重要。



time: make Timer/Ticker channels not receivable with old values after Stop or Reset returns #37196

https://go-review.googlesource.com/c/go/+/568341