规范没有在赋值兼容性中定义任何情况,其中 S
是一个约束为基本类型的类型参数,而 T
是相同的基本类型。
这导致了一些奇怪的错误,例如 T
不能分配给 number
,尽管 T extends number
:
enum E { A, B, C }
enum F { X, Y, Z }
function f<T extends number>(x: T[]): T {
var y: number = x[0]; // Error, T is not assignable to number...??
}
// f<T extends number> is useful:
var x = f([E.A, E.B]); // ok, x: E
var y = f([F.X, F.Y]); // ok, y: F
var z = f(['foo', 'bar']); // Error
6条答案
按热度按时间guicsvcw1#
如果不允许原始类型被扩展,那么编写
T extends number
有什么用处,为什么应该允许它?它似乎并没有限制语言中的任何内容。总有人可以这样编写上面的函数,我认为这样更有意义:
或者我是不是漏掉了什么?
kknvjkwl2#
如果不允许原始类型被扩展,那么编写 T extends number 有什么用处,为什么应该允许?
请参阅原始帖子中的示例
var x
、var y
和var z
。枚举成员是number
的子类型,将函数输入的类型与其输出类型关联起来在限制函数可以处理的类型时是有用的。oyt4ldly3#
好的,这很有道理。顺便说一下,可能有益于添加约束
enum
或EnumMember
的能力。jecbmhm34#
不仅仅是原始类型,类型参数对其约束的不可分配性会带来问题;我也在联合体中遇到过这个问题。这里有一个真实的例子:
类层次结构更糟:
我不明白为什么类型参数的子类型/可分配性需要为每种约束(对象、原始类型、联合体、另一个类型参数等)有单独的规则 - 似乎只需要一个通用规则就足够了:“S是一个类型参数,且S的约束是T的子类型或可分配给T。”
nc1teljy5#
已批准
vcirk6k66#
@jeffreymorlan ,工会问题由#2778解决。但正如你提到的,似乎很愚蠢的是,每种约束都必须得到考虑。可能更正确的做法是递归地检查S的基本约束是否可以分配给T。