Repository navigation
Broken emit when Infinity or ‑Infinity ends up in a type position #42905
Description
Activity
- changed the title
[-]Broken emit when `Infinity` or `-Infinity` ends up in a Type position[/-][+]Broken emit when `Infinity` or `‑Infinity` ends up in a type position[/+]on Feb 21, 2021 You're mixing a bug report and a feature request together in one. Fixing the bug would be to emit the type
numberinstead ofInfinity. Introducing anInfinity(andNaN) type is a feature request, for which you should provide a good reasoning in response to #9407 (comment).Reacted by Armano and Omri LuzonI for one have wanted
Infinity/-Infinityas a special case for things that otherwise take BigInts e.g. ranges:function* bigintRange(low: bigint, high: bigint | Infinity, step?: bigint=1n): Generator<bigint> { for (let i = low; i < high; i += step) { yield i; } }
Reacted by ExE BossJames Browning (@Jamesernator) Just as a general advice: It tremendously helps when you explain your reasoning on why you want this, not just say "I want it for this". In your example you could just as well replace the
Infinitywithundefined. Having a dedicatedInfinitytype would not help you in this case, becauseInfinitywould be a sub-type ofnumber, so the union typenumber | Infinitywould be simplified tonumber. Same as it happens withnumber | 5.Reacted by cadIn your example you could just as well replace the Infinity with undefined. Having a dedicated Infinity type would not help you in this case, because Infinity would be a sub-type of number, so the union type number | Infinity would be simplified to number.
The example is bigint not number. BigInts don't contain an
Infinityvalue, I think it's a lot more readable to use the explicitInfinityvalue rather than some arbitrary token as it already compares correctly with bigints (e.g.bigint < Infinityis alwaystrue, no coercion toNumberhappens).Reacted by ExE Boss, Zzzen and cadJames Browning (@Jamesernator) Just as a general advice: It tremendously helps when you explain your reasoning on why you want this, not just say "I want it for this". In your example you could just as well replace the
Infinitywithundefined. Having a dedicatedInfinitytype would not help you in this case, becauseInfinitywould be a sub-type ofnumber, so the union typenumber | Infinitywould be simplified tonumber. Same as it happens withnumber | 5.More compelling explanations for why these types are needed can be found in #28682 .
Reacted by ExE Boss👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the repro in the issue body running against the nightly TypeScript.
Issue body code block by ExE Boss (@ExE-Boss)
‼️ Exception: Error - error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error. Visit https://aka.ms/ts6 for migration information.Error: error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error. Visit https://aka.ms/ts6 for migration information. at Object.createVirtualTypeScriptEnvironment (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:8128:11) at twoslasher (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:7618:17) at /home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:439:44 at runTwoslashRequests (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:406:56) at run (/home/runner/work/_actions/microsoft/TypeScript-Twoslash-Repro-Action/master/dist/index.js:20096:75) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)Historical Information
Version Reproduction Outputs Time 4.9.3, 5.0.2, 5.1.3, 5.2.2, 5.3.2 👍 Compiled
Emit:export declare const PositiveInfinity: Infinity; export declare const NegativeInfinity: -Infinity;
⚠️ Way slowerFixing the bug would be to emit the type
numberinstead ofInfinity.Wouldn't it be emitting
1e999or something else that's allowed as a literal TS type but equivalent to IEEE 754 infinity? Emittingnumberis still wider than the original type.Reacted by ExE BossThis is fixed in current native TypeScript 7.1.0-dev.20260906.1. With
--declaration --emitDeclarationOnly, TypeScript 4.1.5 and 6.0.3 emitInfinityand-Infinity; consuming the latter reports TS1110 (Type expected).Current native TypeScript preserves
1e1_000_000and-1e1_000_000in the emitted declaration, which compiles cleanly.
Bug Report
🔎 Search Terms
InfinityNaN🕗 Version & Regression Information
💻 Code
⏯ Playground Link
Workbench Repro
🙁 Actual behavior
TypeScript emits
Infinityand‑Infinityin a type position, which are intentionally invalid according to #9407 (comment):🙂 Expected behavior
The
Infinityand‑Infinityvalues are valid in a type position, so that the generated.d.tsfile is valid.Also, it’d be nice to support literal
NaNs, which would allow forNumber.isNaNto be typed as:Related issues