RFC: Design specification for int type in TypeScript #1
Conversation
…tion Co-authored-by: hax <[email protected]>
docs/int-type-considerations.md
Outdated
| 1. **Should `int` be assignable to `number`?** | ||
| ```typescript | ||
| let i: int = 42; | ||
| let n: number = i; // Should this be allowed? |
docs/int-type-considerations.md
Outdated
| let n: number = i; // Should this be allowed? | ||
| ``` | ||
| - **Pros**: Matches mathematical subset relationship, easier migration | ||
| - **Cons**: Loses integer guarantee, may defeat purpose |
There was a problem hiding this comment.
Updated. Document now specifies int → number is safe and allowed (commit 09b7f68).
docs/int-type-considerations.md
Outdated
| 2. **Should `number` be assignable to `int`?** | ||
| ```typescript | ||
| let n: number = 3.14; | ||
| let i: int = n; // Should this be allowed? |
There was a problem hiding this comment.
允许。但要报告warning。
这主要考虑现有代码的迁移。如果直接报错，开发者也做不了什么事情，也就是直接加转换到整数的操作。这促使他们为了快速绕开error而引入不恰当的转换。warning允许开发者先处理更高优先级的事情，等合适的时候集中处理这类问题。这在工程上是更友好的。
可以增加一个compilerOption来控制行为，缺省是warning，但也可设置为error。
There was a problem hiding this comment.
Updated. Document now specifies number → int allows with warning by default, with CompilerOption to configure as error (commit 09b7f68).
docs/int-type-considerations.md
Outdated
|
|
||
| 3. **How should numeric literals be typed?** | ||
| ```typescript | ||
| let x = 42; // Should this be int, number, or 42? |
There was a problem hiding this comment.
Updated. Integer literals infer as int in type position (commit 09b7f68).
docs/int-type-considerations.md
Outdated
|
|
||
| 4. **Type guards:** | ||
| ```typescript | ||
| function isInt(x: any): x is int { ... } // How to implement? |
There was a problem hiding this comment.
编译器本来就不用管。
一般实现方式：
Number.isInteger(x) && x >= int32Min && x <= int32Max
There was a problem hiding this comment.
Updated. Type guard implementation documented with int32 range check (commit 09b7f68).
docs/int-type-considerations.md
Outdated
|
|
||
| 5. **Widening behavior:** | ||
| ```typescript | ||
| let x = 42; // Literal type 42 |
There was a problem hiding this comment.
Updated. Clarified current behavior doesn't infer literal type for let (commit 09b7f68).
docs/int-type-considerations.md
Outdated
| let y: int = x; // Should 42 widen to int? | ||
| ``` | ||
|
|
||
| ### 15. Implementation Phases |
There was a problem hiding this comment.
Updated. Removed all time estimates from implementation section (commit 09b7f68).
docs/int-type-considerations.md
Outdated
|
|
||
| ## Recommendation | ||
|
|
||
| Adding an `int` type to TypeScript is a **major undertaking** with far-reaching implications. Key considerations: |
There was a problem hiding this comment.
Updated. Removed arguments for/against section and recommendations (commit 09b7f68).
docs/int-type-considerations.md
Outdated
| - Could be implemented in 1-2 months | ||
| - Path to full implementation if successful | ||
|
|
||
| ## Conclusion |
…lines Co-authored-by: hax <[email protected]>
hax
left a comment
There was a problem hiding this comment.
有些comments还没有处理。请处理完毕。RFC需要简化，现在太啰嗦了，尤其是无关的社区分析可以去掉，把精力集中在要做的事情上。
rfc/int-type-considerations.md
Outdated
| 1. **Literal inference** (maintains current behavior): | ||
| ```typescript | ||
| const x = 42; // Infers literal type 42 | ||
| let y = 42; // Infers number (not int) |
There was a problem hiding this comment.
Fixed. let y = 42; now infers as int (commit eb6445f).
rfc/int-type-considerations.md
Outdated
|
|
||
| // Design decisions: | ||
| let x = i + b; // Not allowed - type error | ||
| let y: bigint = i; // Allowed - safe conversion |
There was a problem hiding this comment.
Fixed. int to bigint assignment is now disallowed (commit eb6445f).
…ose sections Co-authored-by: hax <[email protected]>
Addressed all remaining comments and simplified the RFC (commit eb6445f):
|
There was a problem hiding this comment.
Pull request overview
This PR proposes a comprehensive design specification for adding a primitive int type to TypeScript. The proposal includes an RFC document outlining design decisions and implementation requirements, along with design exploration tests to validate the behavior of the hypothetical type.
Key changes:
- Complete RFC document specifying
inttype semantics, including int32 range, type compatibility rules, arithmetic behavior, and standard library integration - Design exploration compiler tests demonstrating basic usage, type compatibility, and arithmetic operations
- Fourslash tests for IDE features like completions and quick info
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
rfc/int-type-considerations.md |
Comprehensive RFC document specifying all design decisions for the int type, including type system integration, compiler implementation, standard library changes, and testing requirements |
tests/cases/compiler/intTypeBasic.ts |
Design exploration test demonstrating basic int type usage including declarations, functions, arrays, classes, and generics |
tests/cases/compiler/intTypeCompatibility.ts |
Test exploring type compatibility rules between int, number, literals, and other types including assignability, arrays, functions, and type guards |
tests/cases/compiler/intTypeArithmetic.ts |
Test exploring arithmetic operations with int type including addition, division, mixed operations, bitwise operations, and overflow behavior |
tests/cases/fourslash/intTypeCompletion.ts |
Fourslash test verifying IDE completion behavior for int type in various contexts |
tests/cases/fourslash/intTypeQuickInfo.ts |
Fourslash test verifying hover/quick info display for int type annotations and inferred types |
| 3. **Numeric literals infer as int for integer values** | ||
| ```typescript | ||
| let x = 42; // Infers int | ||
| const y = 42; // Infers literal type 42 | ||
| let z: int = 42; // Explicit int annotation |
There was a problem hiding this comment.
There's a contradiction in the literal inference specification. Line 64 states "Numeric literals infer as int for integer values" with the example showing let x = 42; // Infers int. However, line 241 states "Literals maintain current behavior (no breaking changes)" and line 242 says "Explicit int annotation required".
Line 444 then acknowledges this as a breaking change: "Integer literals now infer as int (breaking change for generic code expecting literal types)".
The document needs to be consistent. If integer literals infer as int for let declarations, this is a breaking change and section 5.1 should acknowledge it. If they maintain current behavior, then line 64 and line 444 need to be corrected.
| 3. **Numeric literals infer as int for integer values** | |
| ```typescript | |
| let x = 42; // Infers int | |
| const y = 42; // Infers literal type 42 | |
| let z: int = 42; // Explicit int annotation | |
| 3. **Numeric literals maintain current behavior; `int` requires explicit annotation** | |
| ```typescript | |
| let x = 42; // Infers number | |
| const y = 42; // Infers literal type 42 | |
| let z: int = 42; // Explicit int annotation (required) |
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
|
@copilot apply changes based on the comments in this thread |
All bot review suggestions have been applied:
The document currently reflects your design decision that |
| type NumberWrapper = { value: number }; | ||
|
|
||
| let iw: IntWrapper = { value: 42 }; | ||
| let nw: NumberWrapper = iw; // Is IntWrapper assignable to NumberWrapper? |
There was a problem hiding this comment.
The comment asks "Is IntWrapper assignable to NumberWrapper?" This follows from structural typing and the RFC rule that int is assignable to number (lines 49-53). Since the value property type is covariant in this context, IntWrapper should be assignable to NumberWrapper. The comment should state the expected behavior.
| let nw: NumberWrapper = iw; // Is IntWrapper assignable to NumberWrapper? | |
| let nw: NumberWrapper = iw; // Per RFC, IntWrapper is assignable to NumberWrapper (covariant value property). |
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Provides a complete design specification for adding a primitive
inttype to TypeScript, with all major design decisions resolved based on maintainer feedback.Changes
Design Document (
rfc/int-type-considerations.md)int→number: Safe and allowednumber→int: Warning by default, configurable as error via CompilerOptionintforletdeclarations, literal type forconstint + int = intint / int = number(may be fractional)numberinttypesint(passingnumbertriggers warning/error)number→intbehavior (warning vs error)value | 0emitint + bigintnot allowed,int→bigintnot allowed (requires explicit conversion)Test Cases (Design exploration)
intTypeBasic.ts: Declarations, functions, arrays, genericsintTypeCompatibility.ts: Type assignability, literal types, unions, intersectionsintTypeArithmetic.ts: Arithmetic operations, bitwise operations, type inferenceintTypeCompletion.ts: IDE completion behaviorintTypeQuickInfo.ts: Hover information displayDesign Decisions (Resolved)
Type compatibility:
intis assignable tonumber(safe).numberis assignable tointwith warning (configurable as error).Literal inference: Integer literals (
42) infer asintforletdeclarations, literal type forconstdeclarations.Division behavior:
a / b(wherea, b: int) returnsnumber(may be fractional).Standard library: Array and String index signatures changed to
int. Math methods unchanged (values may exceed int32 range).BigInt conversion:
inttobigintassignment not allowed. Explicit conversion required viaBigInt()constructor.Implementation Scope
Parser, scanner, and type system changes required across multiple files. Standard library updates for Array/String index signatures. New compiler options for behavior control. Language service integration needed. Comprehensive testing required.
Document Simplification
The RFC has been streamlined to focus on technical implementation requirements. Removed verbose sections on documentation, performance analysis, tooling impact, community ecosystem analysis, and alternative approaches to maintain focus on implementation details.
Original prompt
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.