blocks|key|73533|text|更新:+2019-05-30+TypeScript+3.5版本引入了smarter+union+type+checking，它修复了对象类型(如{a:+"x"}+%7C+{a:+"y"}，但似乎没有对元组类型(如["x"]+%7C+["y"])做任何事情)。我不确定这是不是故意的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|73534|73535|在“示例1”中，a被初始化为"x"这一事实产生了很大的不同。控制流分析将a的类型缩小到只有"x"，尽管您将其注释为"x"+%7C+"y"|73536|let+a:+"x"+%7C+"y"+=+"x";
console.log(a+===+"y");+//+error!
//+This+condition+will+always+return+'false'+
//+since+the+types+'"x"'+and+'"y"'+have+no+overlap.|code-block|syntax|javascript|73537|因此，在这种情况下，[a]当然会匹配["x"]+%7C+["y"]，因为编译器知道[a]是["x"]类型。|73538|73539|因此，示例1只是巧合地成功。一般来说，这是失败的。编译器通常不会将[A]+%7C+[B]等同于[A+%7C+B]。前者被视为一种严格意义上比后者更窄的类型。|73540|type+Extends<T,+U+extends+T>+=+true;
type+OkayTup+=+Extends<[string+%7C+number],+[string]+%7C+[number]>;+
type+NotOkayTup+=+Extends<[string]+%7C+[number],+[string+%7C+number]>;+//+error!|73541|这可能令人惊讶，因为实际上每个[A+%7C+B]类型的值都应该可以赋值给[A]+%7C+[B]类型。当你看一下类似的property-bag版本时，同样的惊喜也会发生：|73542|type+OkayObj+=+Extends<{a:+string+%7C+number},+{a:+string}+%7C+{a:+number}>;
type+NotOkayObj+=+Extends<{a:+string}+%7C+{a:+number},+{a:+string+%7C+number}>;+//+error!|73543|同样，{a:+A}+%7C+{a:+B}被认为是一种严格意义上比{a:+A+%7C+B}更窄的类型，尽管您很难想出后者的值是不能赋值给前者的。|73544|那么，这是怎么回事？嗯，看起来这要么是intentional，要么是TypeScript的design+limitation。Word+of+Language+Architect说：|73545|对于您的示例，为了没有错误地输入|73546|，我们必须将{+x:+"foo"+%7C+"bar"+}形式的类型等同于{+x:+"foo"+}+%7C+{+x:+"bar"+}。但这种等价性只适用于具有单一属性的类型，在一般情况下并不成立。例如，将{+x:+"foo"+%7C+"bar",+y:+string+%7C+number+}等同于{+x:+"foo",+y:+string+}+%7C+{+x:+"bar",+y:+number+}是不正确的，因为第一种形式允许所有四种组合，而第二种形式只允许两种特定的组合。|blockquote|73547|73548|73549|(注意:等价性在比上面提到的稍多的情况下成立...它仅适用于在单个属性的情况下，每个联合成分中不同的属性采用联合的所有可能值的情况。因此，{x:+string+%7C+number,+y:+boolean,+z:+string}等同于{x:+string,+y:+true,+z:+string}+%7C+{x:+string,+y:+false,+z:+string}+%7C+{x:+number,+y:+true,+z:+string}+%7C+{x:+number,+y:+false,+z:+string})|73550|我想说这是一个设计上的限制。检测属性联合可以折叠/扩展的相对罕见的情况将是非常昂贵的，而且不值得实现。|73551|73552|在实践中，如果你发现自己面临着一个联合属性合并的事情，编译器不会验证，但你知道它是安全的，展示你的卓越智慧，并通过assert摆脱它：|73553|function+fn(a:+'x'+%7C+'y')+{
++const+b+=+[a]+as+['x']+%7C+['y']+//+I'm+smarter+than+the+compiler++
}|73554|73555|好的，希望这会有帮助；祝你好运！|73556|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#smarter-union-type-checking|1|https://github.com/microsoft/TypeScript/issues/12052|2|https://github.com/microsoft/TypeScript/issues/8289#issuecomment-214554425|3|https://github.com/microsoft/TypeScript/issues/12052#issuecomment-258653766|4|https://www.typescriptlang.org/docs/handbook/basic-types.html#type-assertions^0|20|J|2W|D|Y|R|0|0|0|8|1|E|3|10|1|19|3|1L|9|0|0|A|3|I|D|13|3|17|5|0|0|X|9|19|7|0|0|F|7|Y|9|0|0|3|F|U|A|0|J|B|1|19|H|2|1R|Q|3|0|0|6|K|Y|R|2P|14|3W|1D|0|0|0|1X|17|37|3R|0|0|0|1L|6|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|21|8|@$9|22|A|23|B|C]|$9|24|A|25|B|C]]|D|@$9|26|A|27|1|28]]|E|$]]|$1|F|3|-4|5|6|7|29|8|@]|D|@]|E|$]]|$1|G|3|H|5|6|7|2A|8|@$9|2B|A|2C|B|C]|$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]|$9|2H|A|2I|B|C]|$9|2J|A|2K|B|C]]|D|@]|E|$]]|$1|I|3|J|5|K|7|2L|8|@]|D|@]|E|$L|M]]|$1|N|3|O|5|6|7|2M|8|@$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|C]|$9|2T|A|2U|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|2V|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|2W|8|@$9|2X|A|2Y|B|C]|$9|2Z|A|30|B|C]]|D|@]|E|$]]|$1|S|3|T|5|K|7|31|8|@]|D|@]|E|$L|M]]|$1|U|3|V|5|6|7|32|8|@$9|33|A|34|B|C]|$9|35|A|36|B|C]]|D|@]|E|$]]|$1|W|3|X|5|K|7|37|8|@]|D|@]|E|$L|M]]|$1|Y|3|Z|5|6|7|38|8|@$9|39|A|3A|B|C]|$9|3B|A|3C|B|C]]|D|@]|E|$]]|$1|10|3|11|5|6|7|3D|8|@]|D|@$9|3E|A|3F|1|3G]|$9|3H|A|3I|1|3J]|$9|3K|A|3L|1|3M]]|E|$]]|$1|12|3|13|5|6|7|3N|8|@]|D|@]|E|$]]|$1|14|3|15|5|16|7|3O|8|@$9|3P|A|3Q|B|C]|$9|3R|A|3S|B|C]|$9|3T|A|3U|B|C]|$9|3V|A|3W|B|C]]|D|@]|E|$]]|$1|17|3|-4|5|6|7|3X|8|@]|D|@]|E|$]]|$1|18|3|-4|5|6|7|3Y|8|@]|D|@]|E|$]]|$1|19|3|1A|5|6|7|3Z|8|@$9|40|A|41|B|C]|$9|42|A|43|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|44|8|@]|D|@]|E|$]]|$1|1D|3|-4|5|6|7|45|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|46|8|@]|D|@$9|47|A|48|1|49]]|E|$]]|$1|1G|3|1H|5|K|7|4A|8|@]|D|@]|E|$L|M]]|$1|1I|3|-4|5|6|7|4B|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|6|7|4C|8|@]|D|@]|E|$]]|$1|1L|3|-4|5|6|7|4D|8|@]|D|@]|E|$]]]|1M|$1N|$5|1O|1P|1Q|E|$1R|1S]]|1T|$5|1O|1P|1Q|E|$1R|1U]]|1V|$5|1O|1P|1Q|E|$1R|1W]]|1X|$5|1O|1P|1Q|E|$1R|1Y]]|1Z|$5|1O|1P|1Q|E|$1R|20]]]]

UPDATE: 2019-05-30 the release of TypeScript 3.5 introduces <a href="https://github.com/Microsoft/TypeScript/wiki/What&#39;s-new-in-TypeScript#smarter-union-type-checking" rel="nofollow noreferrer">smarter union type checking</a> which fixes this for object types (like <code>{a: "x"} | {a: "y"}</code>, but doesn't seem to do anything to tuple types (like <code>["x"] | ["y"]</code>). Not sure if that's intentional or not. 

<hr>

In "Example 1", the fact that <code>a</code> is initialized to <code>"x"</code> makes a big difference. The control flow analysis narrows the type of <code>a</code> down to just <code>"x"</code> despite your annotation as <code>"x" | "y"</code>:

<pre><code>let a: "x" | "y" = "x";
console.log(a === "y"); // error!
// This condition will always return 'false' 
// since the types '"x"' and '"y"' have no overlap.
</code></pre>

So then of course in this case <code>[a]</code> will match <code>["x"] | ["y"]</code>, since <code>[a]</code> is known by the compiler to be of type <code>["x"]</code>.

<hr>

Therefore, Example 1 only succeeds coincidentally. In general, this fails. The compiler does not generally see <code>[A] | [B]</code> as equivalent to <code>[A | B]</code>. The former is seen as a strictly narrower type than the latter.

<pre><code>type Extends&lt;T, U extends T&gt; = true;
type OkayTup = Extends&lt;[string | number], [string] | [number]&gt;; 
type NotOkayTup = Extends&lt;[string] | [number], [string | number]&gt;; // error!
</code></pre>

This may be surprising, since in fact every value of type <code>[A | B]</code> should be assignable to type <code>[A] | [B]</code>. This same surprise happens when you look at the analogous property-bag version:

<pre><code>type OkayObj = Extends&lt;{a: string | number}, {a: string} | {a: number}&gt;;
type NotOkayObj = Extends&lt;{a: string} | {a: number}, {a: string | number}&gt;; // error!
</code></pre>

Again, <code>{a: A} | {a: B}</code> is seen to be a strictly narrower type than <code>{a: A | B}</code>, despite the fact that you'd be hard pressed to come up with a value of the latter type that wasn't assignable to the former.

So, what's going on here? Well, it seems that this is either <a href="https://github.com/microsoft/TypeScript/issues/12052" rel="nofollow noreferrer">intentional</a> or a <a href="https://github.com/microsoft/TypeScript/issues/8289#issuecomment-214554425" rel="nofollow noreferrer">design limitation</a> of TypeScript. The <a href="https://github.com/microsoft/TypeScript/issues/12052#issuecomment-258653766" rel="nofollow noreferrer">Word of Language Architect</a> says:

<blockquote>
 For your example to type check with no errors we would have to consider types of the form <code>{ x: "foo" | "bar" }</code> to be equivalent to <code>{ x: "foo" } | { x: "bar" }</code>. But this sort of equivalence only holds for types with a single property and isn't true in the general case. For example, it wouldn't be correct to consider <code>{ x: "foo" | "bar", y: string | number }</code> to be equivalent to <code>{ x: "foo", y: string } | { x: "bar", y: number }</code> because the first form allows all four combinations whereas the second form only allows two specific ones.
</blockquote>

(Note: the equivalence holds in slightly more cases than mentioned above... it only applies where the properties that are different in each union constituent take on all possible values of the union in the single-property case. So, <code>{x: string | number, y: boolean, z: string}</code> is equivalent to <code>{x: string, y: true, z: string} | {x: string, y: false, z: string} | {x: number, y: true, z: string} | {x: number, y: false, z: string}</code>)

I'd say this is a design limitation... detecting the relatively rare cases where property unions can be collapsed/expanded would be very expensive, and it's just not worth it to implement.

<hr>

In practice, if you find yourself faced with a union property merge thingy that the compiler doesn't verify but that you know is safe, demonstrate your superior intellect and <a href="https://www.typescriptlang.org/docs/handbook/basic-types.html#type-assertions" rel="nofollow noreferrer">assert</a> your way out of it:

<pre><code>function fn(a: 'x' | 'y') {
 const b = [a] as ['x'] | ['y'] // I'm smarter than the compiler 
}
</code></pre>

<hr>

Okay, hope that helps; good luck!

The behaviour of these two examples should be identical, yet the second one errors. Why?

<pre><code>// Example 1:
const a: 'x' | 'y' = 'x'; 
const b: ['x'] | ['y'] = [a]; // ok

// Example 2:
function fn(a: 'x' | 'y') {
 const b: ['x'] | ['y'] = [a];
 // ^
 // Type '["x" | "y"]' is not assignable to type '["x"] | ["y"]'.
 // Type '["x" | "y"]' is not assignable to type '["x"]'.
 // Type '"x" | "y"' is not assignable to type '"x"'.
 // Type '"y"' is not assignable to type '"x"'.
}
</code></pre>

You can <a href="https://www.typescriptlang.org/play/index.html#src=const%20a%3A%20&#39;x&#39;%20%7C%20&#39;y&#39;%20%3D%20&#39;x&#39;%3B%20%0Aconst%20b%3A%20%5B&#39;x&#39;%5D%20%7C%20%5B&#39;y&#39;%5D%20%3D%20%5Ba%5D%3B%0A%0Afunction%20fn(a%3A%20&#39;x&#39;%20%7C%20&#39;y&#39;)%20%7B%0A%20%20%20%20const%20b%3A%20%5B&#39;x&#39;%5D%20%7C%20%5B&#39;y&#39;%5D%20%3D%20%5Ba%5D%3B%0A%7D%0A%0A" rel="nofollow noreferrer">try it on the playground</a>.

TypeScript union of strings not assignable to union of tuples in function

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这两个示例的行为应该是相同的，但第二个示例是错误的。为什么？// Example 1:const a: 'x' | 'y' = 'x'; const b: ['x'] | ['y'] = [a]; // ok// Example 2:function fn(a: 'x' | 'y') {  const b: ['x']...

字符串的TypeScript并集不能赋值给函数中的元组并集-腾讯云开发者社区-腾讯云

问字符串的TypeScript并集不能赋值给函数中的元组并集
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问字符串的TypeScript并集不能赋值给函数中的元组并集EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问字符串的TypeScript并集不能赋值给函数中的元组并集
EN