Golang Go语言一个感觉可读性比官方范型草案要高的提案
Golang Go语言一个感觉可读性比官方范型草案要高的提案
https://github.com/dotaheor/unify-Go-builtin-and-custom-generics
两个对比:
- Map: the draft vs. this proposal.
- Set: the draft vs. this proposal.
更多关于Golang Go语言一个感觉可读性比官方范型草案要高的提案的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
用 function body 做泛型约束,就已经谈不上“可读性”了,新的 contract 提案和旧的比较,最大的不同就是泛型约束的语法不再用 function body。
更多关于Golang Go语言一个感觉可读性比官方范型草案要高的提案的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
这个提案也可以不用 function body 来做约束的。
这下面有很多例子中使用了不带 function body 的 contracts。
https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/tree/master/examples/src/go
个人感觉此提案相对官方草案有以下优点:
1. 和内置范型更接近。
2. 主题语法完全和 Go 1 兼容.
3. 相对于官方草案,少了很多新语法。
事实上,此提案更多地借鉴了 C++模板。C++模板不滥用的时候,其实可读性还是挺高的。
是很像模板
对于大型程序,可读性和对实现代码的依赖是较大的问题
C++搞 concepts 了,Go contract 草案也许可能参考了这个,参见 B.S.老爷子的文章 Concepts: the Future of Generic Programming
和 D 模板还真有店像。
https://en.wikibooks.org/wiki/A_Beginner%27s_Guide_to_D/Templates_and_Generic_Programming/Mixins
应该说兼有 C++(但 type/function 输出)和 D (多个输出)模板的特点。
这老爷子准备把 C++设计成百科全书吗?作为一个只懂 C++98 的大叔,表示看不懂新世纪的 C++代码。
go 不加泛型也挺好的,写出了 docker 和那么多云原生的组件。港真,go 语言没有必要加泛型,避免增加语言复杂度
c++没有 concept 做约束的话,可能展开很多层才抛错,错误信息就很难理解了。contract 是和 concept 很像的
加了范型不想用可以不用啊。但对于某些项目来说,范型很重要。目前 Go 主流项目扎堆于于网络和工具一个重要的原因就是缺少范型。范型可以帮助 Go 开拓新的疆土。
针对您提到的Golang Go语言可读性比官方泛型草案要高的提案,我作为IT领域的Go语言专家,有以下观点:
Go语言一直以简洁、明确著称,其代码可读性高是公认的优势之一。在Go 1.18版本之前,Go语言并未支持泛型,这在一定程度上限制了其代码复用性和类型安全性。然而,开发者们通过接口{}类型等方式,实现了对不同数据类型的支持,但这种方式会引入运行时开销,并可能带来性能损失。
官方泛型草案的提出,旨在通过引入泛型来提高Go语言的代码复用性和类型安全性。泛型允许在编程时使用泛型来代替某个实际的类型,从而达到代码复用的目的。虽然泛型草案的语法和概念对于初学者来说可能稍显复杂,但它提供了更强大、更灵活的类型系统。
对于提案中提到的可读性问题,我认为这更多是一个习惯和适应的问题。随着对泛型语法的熟悉和理解,开发者们会逐渐发现其带来的便利和优势。同时,官方和社区也在不断努力完善泛型的文档和教程,以降低学习曲线和提高可读性。
因此,我认为官方泛型草案是Go语言发展的一个重要步骤,它将在保持Go语言简洁性的同时,进一步提高其代码复用性和类型安全性。