Why does interface comparison have to panic?

agolangf · · 381 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>If two interfaces are compared with <code>==</code> and their concrete types are the same incomparable type, a panic occurs. Why is this not prevented at compile time by specifying &#34;variables of an interface type are comparable if every concrete type that satisfies the interface is comparable&#34;?</p> <hr/>**评论:**<br/><br/>TheMerovius: <pre><p>The rules to do that would be incredibly hard to put into words (for the spec) and code (for the compiler).</p> <p>First, comparing two interface values is fine, storing incomparable values in interfaces is also fine and the code storing a value in an interface and the code comparing it could be in different packages. So, suddenly, at the very least, &#34;an incomparable value can be stored here&#34; must be part of the object file describing a compiled package. But that&#39;s not even enough; because it&#39;s fine to compare two interface values if exactly one of them contains an incomparable type, so you need to look at every combination of interface values at the package-boundary too. But, not even <em>that</em> is enough, because if two incomparable values are saved into a pair of interface values might depend on the exact codepaths taken, so suddenly you need whole-program analysis. But wait, I can construct a program that will have two incomparable values in a compaired pair of interface values, if and only if the axioms of arithmetic are consistent and now the compiler needs to solve the halting problem to decide whether my program is valid, or not.</p> <p>Of course, you could work around that and just say &#34;it&#39;s a compile-time error in the following straight forward cases&#34;, but good luck putting that into a spec that is understandable, succinct and won&#39;t completely bite you in the ass the next time you change your compiler inference capabilities.</p> <p>Interfaces are go&#39;s way to erase compile-time type-information. That&#39;s just the way it is and at that time you can&#39;t make any assumptions about an interface that depends on it&#39;s compile time value, it&#39;s as simple as that :)</p></pre>driusan: <pre><p>How are you going to determine what every concrete type of an interface is?</p></pre>usernameliteral: <pre><p>What if something that is not comparable unintentionally satisfies the interface?</p></pre>Partageons: <pre><p>Then the programmer will be informed at compile time and will be able to fix it. Go literature emphasizes that accidental satisfaction is rarely a problem.</p></pre>dominikh: <pre><p>For starters, that would really break encapsulation. My code would suddenly fail to compile because a third party package that I import added a type that implements my interface.</p> <p>It would make comparing <code>interface{}</code> impossible as well.</p></pre>metamatic: <pre><p>Imagine what that would do for compile times. You&#39;d need a dependency graph too.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

381 次点击  
加入收藏 微博
0 回复
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传