go/types: string(1 < < s) 应该是一个错误

eiee3dmh  于 6个月前  发布在  Go
关注(0)|答案(4)|浏览(48)
package main

func main() {
	var s uint
	_ = string(1 << s)
}

( https://play.golang.org/p/owHsmdZd32v )是一个错误:在 1 << s 中的 1 假定了它在没有移位的情况下的类型,即 string 。cm/compile和gccgo都正确地报告了错误。
go/types似乎接受它。

bogh5gae

bogh5gae1#

在这种情况下(string(number)),字符串转换不仅仅是改变参数的类型,而是积极地改变其值和表示。因此,移位规则不考虑上下文是有道理的。或者反过来看,也许这种转换一开始就不应该被允许,正如通过#3939提出的那样。

wrrgggsh

wrrgggsh2#

在2018年6月27日星期三下午4:20,Tim Cooper ***@***.***>写道:相关 #21981 < #21981 >?
确实如此。谢谢!-gri
...
—您收到此邮件是因为您被分配了任务。请直接回复此邮件,查看GitHub上的<#26096 (comment)>,或者静音线程< https://github.com/notifications/unsubscribe-auth/AIIkTz1DNDGIP360-WywgYHcVHHXxWrjks5uBBMzgaJpZM4U6bt6 >。

vsikbqxv

vsikbqxv4#

在(go/types)conversions.go:61处,我们选择untyped int(string(1 << s)中1的当前类型)作为1的类型(即,我们不改变它)。如果我们不对这种情况(整数到字符串的转换)做任何特殊处理,1的类型将变为srtring,我们将得到预期的错误信息。
不幸的是,什么都不做会导致常规转换(如string('a'))失效,因为转换的参数与字符串不再兼容。
修复这个问题需要更微妙的更改。暂时搁置,因为这a)不太可能在实际程序中发生,b)有简单的解决方法,c)这并不阻止go/types接受合法的程序。
如果我们移除string(int/rune)转换(#3939),这个问题也可能变得无关紧要。

相关问题