为什么对于显而易见的案例没有类型推断？

Question

我经常发现自己需要通过放置显式的注解来解决反射警告，这些注解的类型是完全显而易见的。

(def ^String foo "bar") ;; adding ^String fixes reflection warnings elsewhere

“bar”是一个String，这在编译时是可以明确知道的，所以我感觉我正在做一些费力不讨好的事情，也可能会在以后变得过时。

是否考虑过为这种简单的案例添加“类型推断”？

（“类型推断”这个术语可能对这个用例有些夸张）

...我可以想象至少一个反对意见： (def ^CharSequence foo "bar") 也是一种准确且有用的情况。但一个好的默认设置是推断 x 的类型为 x 的类 - 如果用户想将 x 标注为其祖先之一（此处：CharSequence，Object），则可以手动覆盖推断出的默认设置。

Answer 1

(def foo "bar") 创建了一个 Clojure变量 - 技术上是一种可变的存储形式。

除非有人提供提示，否则无法保证（无论是隐式的还是显式的）代码不会执行类似于 (alter-var-root #'foo #(do % 42)) 的操作。这会使得在核心语言中进行隐式类型推断变得困难。

Comments

我考虑过这个问题，并且alter-var-root可以简单地擦除任何类型注解，如果当前的是推断出来的，而不是由程序员指定的（这可以通过附加的元数据区分开来）。

---

使用alter-var-root在运行时操作中擦除类型提示无法帮助已经使用原始类型信息编译的代码。

---

你也可以观察到，如果以非结构化的方式重新加载代码（无论选择的流程如何）和/或使用低级API，代码可能会被以多种方式损坏。

也许这个特性可以通过例如一个动态var或System属性来控制，对于我们这些关心（并且不会黑客式地加载代码）的人来说。

---

我们当然不反对在可能的情况下添加类型推断，但这个特定的更改不是微不足道的，而且在类型提示有效性的背景下，它不太可能获得支持。话虽如此，Typed Clojure项目可能为这个场景提供了一个令人满意的解决方案，这可能值得探索。 https://typedclojure.org