Clojure 2024 状态调查 中分享你的想法!

欢迎!请参阅 关于 页面了解有关如何使用此站点的更多信息。

0
Java 交互
编辑

我经常发现自己通过放置显然的类型注解来解决反射警告。

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

"bar" 是一个字符串,在编译时无疑是可以知道的,因此在我看来,我正在做一些琐碎的工作,也可能创建一些可能过时的东西。

是否考虑过为这种直接的情况添加“类型推断”?

(“类型推断”可能是这个用例的夸张说法)

...我可以想象至少有一个反对意见:(def ^CharSequence foo "bar") 也可以是准确和有用的。但一个好的默认选择是推断 x 的类型是它的类 - 如果用户希望将 x 标注为其祖先之一(这里:CharSequence,Object),则可以通过手动覆盖推断的默认值。

1 个答案

+1

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

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

我考虑过这个,如果当前类型是推断得出的,那么alter-var-root可以简单地擦除任何类型注释,而不是程序员指定的(通过额外的元数据这似乎很容易区分)。
使用alter-var-root中的运行时行为擦除类型提示并不帮助已经使用原始类型信息编译过的代码。
如果以未结构化的方式重新加载代码(无论选择的流程如何)和/或使用底层API,代码可能会以多种方式被破坏。

也许这个特性可以通过例如动态变量或系统属性来控制,对于那些关心的(而且不会通过篡改加载代码)的人来说。
当然,我们在可能的情况下不反对添加类型推断,但这个特定的更改不是小事,而且在类型提示的效率面前不太可能获得认可。话虽如此,Typed Clojure 项目可能已经为此场景找到了令人满意的解决方案,这可能值得探索。https://typedclojure.org
...