[Discussion] Support for tuple types

[kakasoo]

At the moment, we don't support tuple type, which is actually an array, pointing to [*]. We're thinking about whether to support it or not. If we support this type, it will be a number in parentheses. This requires very deep type reasoning, so performance issues may arise for users with less memory.

Expected

type Answer1 = DeepStrictObjectKeys<[]>; // never
type Answer2 = DeepStrictObjectKeys<['a']>; // '[*]'

Actual

type Answer1 = DeepStrictObjectKeys<[]>; // never
type Answer2 = DeepStrictObjectKeys<['a']>; // '[0]'

[luke0408]

Tuple support is not expected to introduce significant changes. However, as you mentioned, providing tuple type support will likely involve deep type reasoning.

If we proceed with implementation, we propose using different bracket notations to distinguish various types more clearly.

💡 Proposed Approach: Distinguishing [], {}, and ()

Instead of treating tuples as either [*] or [0], we suggest distinguishing between arrays, tuples, objects, and functions:

Type	Current Representation	Proposed Representation
Array (Array<T>)	[*]	[*] (no change)
Tuple ([T])	[0]	([0])
Object ({ key: T })	{}	{} (no change)
Function (() => T)	{} or [*]	()

✅ Why This Approach?

• Preserves consistency with existing representations while refining tuple handling.
• Avoids deep type recursion, mitigating performance issues.
• Clearly differentiates tuples (([0])), objects ({}), and functions (()).

⚠️ Considerations

• Potential learning curve for users adapting to ([0]).
• Implementation complexity in modifying existing type logic.
• Backward compatibility with existing [0] usage should be reviewed.

This approach maintains DeepStrictType’s design philosophy while providing a scalable and structured way to handle tuples.
Would love to hear your thoughts on this!