建议
🔍 搜索词
any vs unknown, any strict, unknown strict, unknown as any, any as unknown in strict
✅ 可实现性检查清单
我的建议符合以下准则:
- 这不会对现有的TypeScript/JavaScript代码造成破坏性的更改
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不根据表达式的类型发出不同的JS的情况下实现
- 这不是一个运行时特性(例如库功能、带有JavaScript输出的非ECMAScript语法、JS的新语法糖等)
- 这个特性将与 TypeScript's Design Goals 的其他部分一致。
⭐ 建议
我们有很多情况下希望人们在eslib、DOM、DT和模块中选择使用 unknown
而不是 any
。我们已经在内部讨论了关于第三个原始值的想法,但这很棘手,因为它需要找到一个好的词来描述这个概念,会破坏 .d.ts
向后兼容性,而且这是一个非常细粒度的更改。
我建议我们有一个标志,可以让 unknown
在联合缩小中击败 any
,我们将其归类为比严格更严格的类别。
从3.6开始一直到现在:
type A = any | unknown
// ^? - type A = any
未来的发布
// @thisCompilerFlag: true
type A = any | unknown
// ^? - type A = unknown
4条答案
按热度按时间l7wslrjt1#
Could maybe also be used for things like:
unknown
instead ofany
when failing to resolve a type #46330imzjd6km2#
我刚想到一个替代方案,结果发现它非常接近 #45605
在用户代码(
.ts
文件)到达时,向编译器添加一个选项,强制将源自于.d.ts
文件的any
或unknown
类型转换为any
或unknown
。用户仍然可以在自己的代码中决定使用any
或unknown
类型。我认为这也符合,甚至可以取代"useUnknownInCatchVariables"
。例如:
a.d.ts:
b.ts:
这将是行为:
c.ts (
{ "anyOrUnknownLibType": "as-is" }
默认)c.ts (
{ "anyOrUnknownLibType": "any" }
)c.ts (
{ "anyOrUnknownLibType": "unknown" }
)我认为这个好处是:
fhg3lkii3#
如果可能的话,我认为remcohaszing的#46347(评论)实际上可能会更干净地解决问题。同时减轻作者的负担并将控制权交给用户的能力是非常具有变革性的。它有望帮助减少困惑。(我觉得
any | unknown
对某些人来说可能会令人困惑...并且需要对文档进行一些更新。)dgtucam14#
我们是否可以设置一个严格的编译器标志,引入额外的内置库文件?通过设置各种类型为
unknown
来覆盖通常的版本,例如将JSON.parse
覆盖为返回unknown
。然后我们可以将其与标准库文件一起维护吗?