1
yuchenyang1994 2020-06-17 10:04:29 +08:00
天天喊要来了,倒是发布啊
|
2
fiypig 2020-06-17 10:05:46 +08:00
最快不是明年八月
|
3
mijimoji 2020-06-17 10:06:08 +08:00
期待很久了
|
4
keepeye 2020-06-17 10:07:03 +08:00
1.5 要等到 8 月份发布 2 不知道何年何月了
|
5
echo1937 2020-06-17 10:16:25 +08:00
扫了一样,这还没来(发布)啊,只是更新了一下这个问题的进展。
|
6
lewinlan 2020-06-17 10:22:00 +08:00 via Android
天天喊要来了 /吃瓜
|
7
putaozhenhaochi 2020-06-17 10:22:24 +08:00 via Android
讨厌泛型 /Doge
|
8
boretothee 2020-06-17 10:30:39 +08:00
interface 它不香吗(手动狗头)
|
9
jon 2020-06-17 10:31:47 +08:00
够二啥时候出
|
10
nimdanoob 2020-06-17 10:32:20 +08:00
我记得 go 最初的设计 不是不考虑泛型吗
|
11
iRiven 2020-06-17 10:32:57 +08:00
非常期待
|
12
timothyye 2020-06-17 10:35:02 +08:00
Hmmmm, Go 的官方 blog 也挂了 “Black Lives Matter”
|
13
lower 2020-06-17 10:35:30 +08:00
赶紧出,马上学
|
14
timothyye 2020-06-17 10:37:11 +08:00
预计最早得明年 8 月了。
The earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021 |
15
maoxs2 2020-06-17 10:38:47 +08:00 via Android 1
那以后 struct 的带多返回值方法要是用泛型是不是就四对括号了…
|
16
syrupofplum 2020-06-17 10:42:56 +08:00 2
狼来了
|
17
gramyang 2020-06-17 10:53:11 +08:00 14
可想清楚了,一旦引入泛型,那么 interface{}还有 [大道至简] 可就没了
|
18
imkerberos 2020-06-17 10:56:01 +08:00
@gramyang 不要这么打脸啊.
|
19
securityCoding 2020-06-17 11:01:50 +08:00
@nimdanoob 官方肛不住了,哈哈
|
20
Rwing 2020-06-17 11:02:15 +08:00
和 C# 的泛型有啥区别?
|
21
iscraft 2020-06-17 11:15:17 +08:00
请问下各位大佬,官方的这个例子中:
(s []T)是字符串切片参数,那前面的(type T)是什么意思呢 是对 s 的类型声明吗? 求解答 |
22
duanquanyong 2020-06-17 11:17:10 +08:00
泛型还是有必要的,没有泛型有时候真的很麻烦
|
23
Vegetable 2020-06-17 11:18:11 +08:00 1
|
24
winterbells 2020-06-17 11:38:39 +08:00 via Android
明天起源 2,后天大行动,大后天 GTA6
|
25
dbskcnc 2020-06-17 11:42:34 +08:00
这个新的提议还是有进步的,比之前的更加融洽
|
26
araraloren 2020-06-17 11:52:33 +08:00
是这种吗 () () () () .....
|
27
vus520 2020-06-17 12:01:16 +08:00
表示难受
|
28
linghutf 2020-06-17 12:07:27 +08:00 via Android
泛型怎么定义可比较呢?有点好奇
|
29
kidlj 2020-06-17 12:36:02 +08:00
"The design is fully backward compatible with Go 1" —— Go team 太疯狂了,Go 2 遥遥无期哈。
|
30
beyondex 2020-06-17 12:38:57 +08:00
.NET Core 发来贺电。
|
31
Jirajine 2020-06-17 12:45:31 +08:00 via Android
有了泛型和简化的错误处理 golang 就基本上可以广泛使用了,但这样缝合还保持向后兼容,一致性和“哲学”都没了。
|
32
ppphp 2020-06-17 12:47:16 +08:00
一些标准容器用泛型支持就行了,再多就烦了,有泛型如果还是动态派发其实没啥意思,不过要是能 hkt,还是不错的
|
34
hantsy 2020-06-17 12:55:00 +08:00
Go Interface 实现不需要声明,真受不了,碰瓷式的一不留神说不定实现了某接口。。。
|
35
Hellert 2020-06-17 12:55:14 +08:00
比起泛型,还是更期待能原生支持 10 进制小数。
|
36
hantsy 2020-06-17 12:56:32 +08:00
Go Interface 实在别人费解,interface{}是个任人打扮的 XX 。
|
37
lithbitren 2020-06-17 12:57:37 +08:00
没有泛型真的很难简洁的实现类似 py 或 rs 那种复杂迭代器,希望尽早问世
|
38
lithbitren 2020-06-17 13:26:58 +08:00
还有有了泛型,起码标准库里好些函数方法不用提前实现一大堆接口了,比如堆的实现,每次用得实现 5 个方法,甚至不如直接手撕二叉堆,性能也不如手撕。
|
39
wangyzj 2020-06-17 13:39:40 +08:00
interface{}不香吗
|
40
scnace 2020-06-17 13:41:04 +08:00 via Android
「大道至简」的老一辈基本都快退休了🙈
|
41
PiersSoCool 2020-06-17 13:42:00 +08:00 1
不是很明白 泛型和简洁有什么关系 有了泛型 就不简洁了吗
没了泛型 排序代码要写多少种 |
42
cmdOptionKana 2020-06-17 13:59:51 +08:00 6
Go 团队真的很稳,很耐心挑选方案。
而且他们的思路也很正确,尽量把复杂性留在 “写” 泛型那边,而在 “用” 泛型那边则尽可能简化,这个设计原则非常棒。 比如,官方的例子 Print 函数使用了泛型,它是这样使用的: Print([]string{"Hello, ", "world"}) //输出 Hello, world Print([]int{3, 4, 5}) //输出 345 如果不管 Print 是怎么实现的,只看它是怎么使用的,就会觉得非常简洁,而且兼容 Go 1 。 |
43
lxml 2020-06-17 14:34:54 +08:00
有基本能用的泛型对于底层库第三方库都是好事,只是希望不要大幅增加编译时间就行
|
44
Kisesy 2020-06-17 15:25:05 +08:00
|
45
ChristopherWu 2020-06-17 15:35:33 +08:00 1
想要泛型,不如来先一起做 betterGo: https://github.com/PioneerIncubator/betterGo
|
46
rockyou12 2020-06-17 15:36:37 +08:00 3
不得不说,不用尖括号<>的泛型真的丑啊……虽然再丑的东西用习惯就好,但()()()()()()要是 ide 不给不同括号不同颜色我真的眼睛会花……
|
47
joesonw 2020-06-17 15:39:30 +08:00
@PiersSoCool 生成器还是能解决大部分泛型场景. 如 https://github.com/a8m/syncmap
|
48
zjupigeon 2020-06-17 15:43:03 +08:00
Yellow Lives Matter
|
49
ChristopherWu 2020-06-17 15:46:20 +08:00
@joesonw 生成器不好做- -,可以看看我上面的项目。
|
50
AlohaTing 2020-06-17 17:31:49 +08:00
狼来了这么多次了,也没看见一次啊 ( doge
|
51
whoami9894 2020-06-17 17:40:23 +08:00
不知道是不是习惯了 Cpp 的写法,这样写`func Print(type T)(s []T)`我觉得很丑
|
52
fengjianxinghun 2020-06-17 17:43:52 +08:00 6
@cmdOptionKana 又开始尬吹了,敢问主流泛型那个不是这样?
|
54
liulaomo 2020-06-17 18:23:16 +08:00
@cmdOptionKana
> 而且他们的思路也很正确,尽量把复杂性留在 “写” 泛型那边,而在 “用” 泛型那边则尽可能简化 用这边怎么设计都会很简化。关键看能不能把 “写” 泛型也给简化了,否则不是一个好设计。 |
56
fengjianxinghun 2020-06-17 18:26:22 +08:00
@liulaomo 因为接收器泛型的时候可以有 4 个括号。
|
57
liulaomo 2020-06-17 18:32:43 +08:00
@fengjianxinghun 对,我也看着一大堆()不爽,但是何必非得使用<>这种异物呢?和内置泛型统一起来不香吗?
|
58
ica10888 2020-06-17 18:57:34 +08:00 via Android
看起来是为了兼容之前的语法,希望不要成为第二个 try proposal 。
|
59
CosimoZi 2020-06-17 19:04:53 +08:00 via Android
恭喜 golang 终于要入类型系统的门了
|
60
blless 2020-06-17 20:36:49 +08:00
reddit 各种代码都出来了 反观 v 站,这就是程序员论坛吗
|
61
ThanksSirAlex 2020-06-17 22:24:55 +08:00 via iPhone
最早都要明年 8 月
|
63
tianshilei1992 2020-06-17 22:46:58 +08:00
@whoami9894 习惯了 C++ 的写法觉得其他的都丑,然而所有年轻的语言都觉得 C++ 的写法反人类…😂虽然我一直是 C++ 吹,但是我知道大部分的人都认为 C++ 的语法很反人类,比如说 lambda…
|
64
ConradG 2020-06-17 22:50:41 +08:00
别造成 py2 和 py3 级别的分裂就谢天谢地了
|
65
prenwang 2020-06-17 23:15:58 +08:00
interface 坑的一逼, 装箱拆箱跟玩魔术一样, 泛型快到碗里来
|
66
CoderGeek 2020-06-18 01:30:05 +08:00
好的 等出来我再转 go hhh
|
67
Balthild 2020-06-18 01:57:47 +08:00
@tianshilei1992 别偷换概念,这里「习惯了 C++ 的写法」特指 C++ 采用的这种尖括号泛型语法,你把 C++ 换成 Java 、Rust 、TypeScript 也一样成立。而年轻语言觉得「 C++ 的写法反人类」指的是 C++ 的其他特性,显然这些被批判的部分并不一定包括泛型语法。
|
68
Trim21 2020-06-18 02:55:22 +08:00 via Android
这个 go2go 工具转换出来的代码是什么样子的…
|
69
islxyqwe 2020-06-18 08:30:03 +08:00
func Map(type T, M)(f func(T) M, s []T) []M {
result := make([]M, len(s)) for k, v := range s { result[k] = f(v) } return result } func main() { Print(Map(func(a int64) string { return strconv.FormatInt(a, 16) }, []int64{42, 100, 200})) } 还可以,处理数据总算能写的简洁点了 |
70
jmyz0455 2020-06-18 08:54:36 +08:00
go2 快来了,怕是又有一波降级
|
71
liberty1900 2020-06-18 09:05:56 +08:00 via Android
恭喜,程序可读性将会一去不复返
|
72
asche910 2020-06-18 09:22:10 +08:00
interface 又不是不能用(狗头)
|
73
FrankHB 2020-06-18 09:24:45 +08:00 1
@rockyou12 <>是病,得治。
这种 angle bracket 的习惯来自数学符号,正宗写法是 chevron ( ⟨ ⟩ ),只是在只有基本字符集支持的语言中才复用了大于小于号(<>)。结果词法歧义上就炸了……(看看 C++ >>。) 没看到歧义还觉得不丑,说明基本的实用审美已经被整得退化了。 技术上这种东西还真不如 () 加 tag,因为用 () 在文法歧义之前已经直接承认语义上的潜在歧义,因此正常的设计中会更积极地消歧义(如通过另外加关键字)。 无条件混用 <> 仍然是垫底的弟弟设计。 |
74
FrankHB 2020-06-18 09:32:54 +08:00
@Balthild C++ 反人类的设计显然包括不知所谓的本该避免的文法歧义,使用 <> 多出来的问题就是 C++ 反人类设计的典型杰出代表之一,这不因为其它问题更拉仇恨而改变。你没有一下子搞清楚这点,而强调“并不一定”,看来是不够熟悉 C++ 。(事实是,不想硬抄 instantiation phase 而老实写形式语法的根本没法在实用上绕过这坨○。)
虽然其它许多用 <> 的语言并没有那么夸张的歧义问题,但是用 <> 的必要性仍然相当莫名其妙,有不尊重语用来源之嫌。 选择照抄 C++ 这样设计的语言设计者和语言的用户,大概也不一定了解 C++ 在这方面的历史包袱。而选择不照抄 C++ 却同样使用这种糟粕设计的语言设计者,大概至少一样无可救药(至少没几个语言有当初 C++ 对 basic source character set 那么纠结的需求,也不是事后才扩展出 template 的)。 |
75
Darain 2020-06-18 09:45:39 +08:00
我最早看到 golang 2.0 说要支持泛型还是在 8102 年
|
76
releaseme 2020-06-18 09:49:38 +08:00
@cmdOptionKana 下意识觉得你在黑 Go,再读一遍又觉得不对
|
77
allenhu 2020-06-18 09:51:59 +08:00 via Android
该有的你还得有 doge
|
78
gravitybox 2020-06-18 10:18:20 +08:00
func Print(type T)(s []T) (int, string){
return 0, "" } 这括号也太多了吧 |
80
notamail 2020-06-18 12:17:00 +08:00
@lithbitren 你可以看看 container/list
|
81
lithbitren 2020-06-18 12:22:09 +08:00 via iPhone
@notamail list 还好吧,而且队列手写也好写啊,直接用数组性能比 list 快几倍,我说的是 container/heap
|
82
qW7bo2FbzbC0 2020-06-18 12:35:25 +08:00
当初夸 go 不加泛型和官方秉承简洁不多加功能的人会不会回去改掉他们的文章
|
83
einsdisp 2020-06-19 19:23:05 +08:00
泛型是 golang 最大的痛点(没有之一)。
golang 其他为人诟病的地方(比如错误处理,比如黑魔法太少),大约可归类为习惯问题,if err != nil 只是写法不一样,习惯之后,也足够用了,何况 goland 对于未处理的错误会标黄提示。 但是没有泛型这个实在不能忍,不仅代码丑陋,而且缺少类型提示与编译期错误检查(如果使用 interface{}、反射来曲线救国),运行时性能损失倒无所谓,绝大多数 golang 项目性能绝非瓶颈。 golang 官方从一开始就说没有泛型只是不好实现(怕拖慢编译速度),而不是彻底不考虑未来加入泛型的可能。 根据[golang 官方的开发者调查]( https://blog.golang.org/survey2019-results): > Among the 25% of respondents who said Go lacks language features they need, 79% pointed to generics as a critical missing feature 对于语言特性缺失的调查,其中 79%都指向缺少泛型 |
84
chai2010 2020-06-23 16:00:56 +08:00
看各个群里和论坛的评论,对 Go2 都是褒贬不一。
我想说的是,这是别人的语言,不可能 100%符合自己的口味,美帝不卡你脖子已经够意思了。 如果真不爽,就直接操刀 ast 搞一个自己的定制语言。 gofmt 和 golint 检查也是基于 ast 做分析。 基于 ast 可以扩展出新的语法来,比如七牛面向数据科学语言的 Go+语言。 可以简单看看这本书:《 Go 语法树入门——开启自制编程语言和编译器之旅!》( github 地址:chai2010/go-ast-book ), 其实也就是把 ast 包里的代码简单讲讲。 当然为了写这个书,我们也定制了一个凹语言:目前已经是一个可以嵌入 Go 语言的脚本语言, 也是基于 Go 语言的 ast 定制,在语言的基本功能完成之后我们会公开代码。 |