Description
Search Terms
non sparse array.
(I read and understand (I supouse): #10272 #13778 )
Suggestion
Add a way to declare Non Sparse Arrays to take adventajes of type guards to have these adventajes:
- detect trys of creating sparse arrays
- no need to control if a poped or accessed elemet is not undefined
It could be something like: type a: NonSparse<ElementType[]> or type a:NonSparseArrayOf<ElementType>
Use Cases
Knowing and wanting that an array haves non undefined values.
Examples
/////////// Actualy ///////////
type Ene={n:string}
var a:Ene[]=[{n:'uno'},{n:'dos'},{n:'tres'}];
if(a.length){
var e1 = a[a.length-1];
var e2 = a.pop(); // e1 and e2 points to the same obj
8591
ect
console.log(e2.n); // [ts] Object is possibly 'undefined'.
console.log(e1.n); // no error detects in e1 why?
}
/////////// SUGGESTION ///////////
type Eme={n:string}
var a:NonSparse<Eme[]>=[{n:'uno'},{n:'dos'},{n:'tres'}];
if(a.length){
var e1 = a[a.length-1];
var e2 = a.pop(); // e1 and e2 points to the same object
console.log(e2.n); // ok a is NonSparse
console.log(e1.n); // ok a is NonSparse
a.push({n:'tail'}); // ok
a.unshift({n:'head'}); // ok
a[a.length] = {n:'tail2'} // ok, same as push
a[a.length+1] = {n:'far 1'} // ERROR, sparse
a[7] = {n:'far 2'} // ERROR, may be sparse
var i=8;
a[i] = {n:'far 3'} // ERROR, may be sparse
if(i <= a.length){
a[i] = {n:'far 2'} // ok, guard guarantees non sparse array
}
delete a[i]; // ERROR, me be transforming a into sparse array
if(i >= a.length){
delete a[i]; // ok, guard guarantees non sparse array
}
}
/////////// CASE OF USE ///////////
async function callSeq1(listOfFunctions:NonSparse<(()=>Promise<void>)[]>):Promise<void>{
while(listOfFunctions.length){
var f = listOfFunctions.pop();
await f(); // [ts] Cannot invoke an object which is possibly 'undefined'.
}
}
/////////// WORKARROUND ///////////
async function callSeq2(listOfFunctions:NonSparse<(()=>Promise<void>)>[]):Promise<void>{
var f;
while(f = listOfFunctions.pop()){
await f();
}
}Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. new expression-level syntax)