Golang Go语言中一种兼容性更好的泛型设计
Golang Go语言中一种兼容性更好的泛型设计
最近我在我设计的 Lite 语言中探索了一种新的泛型语法,因为 Lite 从 Go 中借鉴了不少语法,所以这种泛型语法对于 Go 可能也有一定的参考价值。
identifier<T>
这种最主流的语法比较大的问题是与比较操作符冲突,同时也与位操作符冲突,因此我不赞同这种设计。
Scala 的identifier[T]
语法比前面的语法有更好的观感,但解决了上面的冲突之后又与索引语法 identifier[index]
产生了新的冲突,
为此 Scala 的索引语法改为了 identifier(index)
。 这对于已经采用[]
作为索引的语言来说效果也不算很好。
在 Go 的草案中,声明泛型使用 (type T)
的方式,这不会造成冲突,因为type
是关键字,但是调用的时候依然需要编译器进行更多判断才能解决 identifier(type)(params)
的冲突问题,虽然它比以上的方案都好,但仍然不能让我满意。
偶然的机会让我想起了 OC 中方法调用的特殊语法,这给了我一种新语法的灵感。
如果我们将标识符和泛型组成一个整体,一起放入 []
如何?
我们可以得到这个语法 [identifier T]
, 这个语法不会与索引语法产生冲突,因为它必然存在至少两个元素,中间使用空格隔开。
当存在多个泛型时,我们可以这样写 [identifier T, V]
,同样不会与现有的语法产生冲突。
将这个语法代入 Go 中,我们可以得到下面的例子。
E.g.
type [Item T] struct {
Value T
}
func (item [Item T]) Print() {
println(item.Value)
}
func TestGenerics T, V {
a := [Item T]{}
a.Print()
b := [Item V]{}
b.Print()
}
func main() {
TestGenerics int, string
}
这看起来非常清晰。
使用 []
的另一个好处是,与 Go 原本的 Slice 和 Map 语法有一定传承性,不会造成割裂感。
[]int -> [slice int]
map[string]int -> [map string, int]
我们可以造一个更复杂的例子
var a map[int][]map[string]map[string][]string
var b [map int, [slice [map string, [map string, [slice string]]]]]
这个例子依然能保持比较清晰的效果,同时对编译造成的影响很小。
我已经在 Lite 中实现并测试了这个语法,在 Lite 中效果很好,没有产生歧义。
这个设计也许值得引起讨论,我已经在 github 上提交了一个 issue,欢迎一起来讨论。
更多关于Golang Go语言中一种兼容性更好的泛型设计的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
L i s p
直接说 S-Exp 就好了(
更多关于Golang Go语言中一种兼容性更好的泛型设计的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
甚至逗号都不需要,直接用空格区分多参数(
不过多参数是万恶之源,应该柯里化一下,做成 * -> * -> * 的模式(
var b [map int, [slice [map string, [map string, [slice string]]]]]
这个套的眼花了都,不觉得有多清晰,使用<T>的方式,更多是大家都是这样用的,更熟悉,
<>
var b map<int, slice<map<string, map<string, slice<string>>>>>
var b [map int, [slice [map string, [map string, [slice string]]]]]
相比之下,我还是觉得比<T>的方式清晰一些。
换汤不换药
楼主你的 Lite 语言,运算符设计的太复杂了
觉得只是 [] 比 <> 占的显示控件笑了,[doge]
显示空间小了
用 Java 多了,还是感觉<>好
可能是我 go 写太多了吗?我觉得楼主最后举的例子 go 的例子看起来挺显然的…
这个不是设计,是一种语法吧
"identifier<T> 这种最主流的语法比较大的问题是与比较操作符冲突,同时也与位操作符冲突,因此我不赞同这种设计。"
这个前提就不对。操作符和类型声明出现的位置完全不一样,在解析成 AST 之前就可以区分清楚了,对于编译器来说是属于比较容易解析的语法。
就比如括号 ( ) ,非常常见的符号,并且有多种语法,也没有冲突的问题。
语法首先是为语义服务的。先设计功能,再设计语法。所以,到底冲不冲突,最终是要看该语法被用来支持哪些语义。用其它语言的泛型设计来推断 Go 的语法本身也是有问题的。
scala 没有索引语法,只是 apply 函数而已
的确是复杂,一开始特性少还好,后来特性越来越完备,复杂性就升上去了。只要功能多,复杂是必然的了。
主要还是类似 s-expr 的语法比<T>形式的界限看起来清晰一些,把[]换成<>其实也会比原来的看起来清晰。
可是不适合 go 啊,go 草案已经排斥了<>。不然也不会有机会来讨论这个语法。
这么说也对,语法设计。
曾经我也是这么想,直到后来自己写了个编译器才发现问题。
你说的没错,的确不适合已经用[]去处理索引的语言。
第一眼看过去就是 lisp 啊,不过确实挺好。
对我这个对 go 语法还有点陌生的人来说,看的轻松。
看惯了 c/c++, 现在看 go 总是要转换一下思维。
现在特别赞同傻白甜设计。
在Golang中引入泛型是一项重大进步,它增强了代码的复用性和灵活性,同时保持了Go语言一贯的简洁和高效。Go语言的泛型设计在追求兼容性的同时,也充分考虑了易用性和性能。
Go语言的泛型通过类型参数(type parameters)和类型集(type sets)来实现。类型参数允许函数、类型或方法接受一个或多个类型作为参数,从而可以在不同的类型上操作而无需重复代码。类型集则定义了类型参数可以接受的类型范围,这有助于在编译时捕获类型错误,提高代码的健壮性。
为了保持兼容性,Go语言的泛型设计采用了较为保守的策略。它没有引入复杂的模板元编程或类型推导机制,而是采用了更直观和易于理解的语法。这使得即使是没有泛型编程经验的开发者也能快速上手,并编写出高质量的泛型代码。
此外,Go语言的泛型设计还充分考虑了性能。编译器会对泛型代码进行类型特化和内联优化,以确保生成的代码与手动编写的非泛型代码具有相当的性能。这消除了开发者在使用泛型时可能存在的性能顾虑。
总的来说,Go语言的泛型设计在追求兼容性的同时,也充分考虑了易用性和性能。它使得开发者能够编写出更加通用和可复用的代码,同时保持了Go语言一贯的简洁和高效。随着Go语言生态的不断发展,泛型将成为越来越多开发者手中的利器,推动Go语言在更多领域的应用和发展。