Question
When can arrays be cast to tuples with a single as assertion
Given the following assertions are all permitted:
//1. A readonly number[] can be cast to readonly tuple. Despite the length of array being unknown.
([] as readonly number[]) as readonly [number, number, number]
//2. Similarly, a number[] can be cast to tuple. Again despite the length of the array being unknown.
([] as number[]) as [number, number, number]
//3. Additionally, a number[] can be cast to a readonly number[]
([] as number[]) as readonly number[]
So from this I understand that it is possible to cast a number[] to a tuple. So the compiler accepts that I want to make that assertion. I am also able to make assertion that casts an array to a readonly array.
So I guess I am considering these two assertions as individual assertions with independent "features" of the types. The first one concerned with the array vs tuple only. And the second one with readonly vs not readonly. So I suppose by trying to combine these assertions, I might expect that I could assert an array as a readonly tuple, for example:
([] as number[]) as readonly [number, number, number]
But this is not allowed. So maybe it's not correct for me to think about this assertion as a kind of composition/combination of two other assertions that both are only concerned with one feature of the types. But rather this may need to be considered as a third independent assertion with its own rules.
I hope that's a bit more clear. Here's an updated playground link.
Additionally, I can do
([] as number[]) as (readonly number[]) as readonly [number, number, number]
Which I guess is close to some formally more correct way of doing it. And if that's true, and the question then reduces itself to why the need to make individual assertions, then I also understand that perhaps there is not a better answer than that's the way typescript was designed. From what I understand, typescript, by design, does not define some formal set of rules that work almost mathematically, but is more concerned with ease of use and convenience for most cases.
But either way, if there are insights that can make understanding the scenario I have outline more clearly, it is appreciated. Thank you.