Type checking element typed arrays

[bradzacher]

TypeScript Version: 2.3.4

Code

function fn(arg : ('a' | 'b')[]) { }

// ONE
// type checked okay
fn(['a', 'b'])

// TWO
const x = ['a', 'b']
fn(x)
// throws type check error:
// Argument of type 'string[]' is not assignable to parameter of type '("a" | "b")[]'. Type 'string' is not assignable to type '"a" | "b"'.

Expected behavior:
calling case TWO should pass the type check fine

Actual behavior:
case TWO throws type check error:
Argument of type 'string[]' is not assignable to parameter of type '("a" | "b")[]'. Type 'string' is not assignable to type '"a" | "b"'.

typescript automatically casts the variable x to type string[], and in doing so loses all information about its contents, which is why it fails the strict value check.

this is a problem because it means you can't pass reusable arrays without strictly typing the original variable, which causes problems when using generics (a bit of a contrived example, but still):

function fn<T>() {
 return function<TField extends keyof T>(fields : TField[]) { }
}

const StructType = {
 a: 1,
 b: 2,
}
// have to manually define the same type as the inner generics, which kind of ruins encapsulation.
const x : (keyof typeof StructType)[] = ['a', 'b']

fn<typeof StructType>()(x)
// other stuff...
fn<typeof StructType>()(x)

[KiaraGrouwstra]

Yeah, might be nicer if it'd just infer type ['a', 'b'] on assignment, deferring degeneration until needed (if at all).

[Arlen22]

But how on earth can you guarantee that nothing called x.push()? The compiler can't, but you can know that and are telling the compiler that. But it would be really nice if there was a separate syntax to declare a Tuple that would keep the typing as a tuple.

[mhegazy]

literal types are only inferred, in mutable locations, if there is a contextual type. this is mainly a backward compatibility guarantee.

[KiaraGrouwstra]

Mohamed Hegazy (@mhegazy):

backward compatibility

Hm. If ['a', 'b'] < string[], how could switching it to the former break code? I must be missing something...

[Arlen22]

It is actually more strict, as you could be assigning ['x', 'y', 'z'] as string[] to something typed as ['a', 'b'].

[bradzacher]

Yeah it would be nice if I could strictly define the array as a tuple so that the compiler can be sure I haven't pushed to it, etc.

It'd be good because then people could choose to use it as the way they default create arrays, same way generally you default to const for variable decls.

I.e. Have a tuple array construct which forces the compiler to treat the array as truly immutable (but still emit a normal js array).

[Arlen22]

Well you can do const myTup: [ string, string ] = ['a', 'b'], or even better const myTup: [ 'a','b' ] = ['a', 'b'], but I doubt you need that in a tuple. Actually, const myTup: [ 'a','b' ] will eventually become ('a'|'b')[], so I guess that still doesn't keep the ordering.

You could always spin your own definitely typed class, I suppose, though I don't know for sure how it would exactly work. Seems like it would be doable.

A tuple syntax or marker would be really nice so we don't have to declare the type and the value separately. Makes it really handy for chaining promises and observables.

[KiaraGrouwstra]

Even if defaulting to granular types (tuples, string/number/boolean literals) would somehow break some edge cases, perhaps using a compiler flag like for strictNullChecks could prevent that?

[Arlen22]

It would break most code, because most of the time you don't think about it, but any literal that is not a constant is predicted to change in value, though not in type. An Array literal might not be as likely to, but it would probably still break a lot of code.

But adding new syntax wouldn't break anything.

[KiaraGrouwstra]

Actually, if limited to const, is this really still a breaking change? I believe ++ is already disallowed there; not sure if array push is disallowed for const as well (on phone so can't check), but if so, I'm not sure that should be considered more feature than bug.

Edit:

Sounds like a candidate for a compiler flag. Libraries won't suffer much, as their types will get distributed as .d.ts, making them immune to the user's compiler flags.
In user land, I've taken it immutability has gained some traction. I'd say let people try if they like it and see how it goes.
That said, maybe there could be a middle ground where a granular mode would actually distinguish const and let.

[Arlen22]

No, array push is definitely allowed on const. This is due to the intent of const, where a variable's pointer is declared readonly, so you know you will never accidently assign a different value to (for instance) the NodeJS Path module and you will always be using the same object reference.

[Arlen22]

If you want a definite readonly or frozen object, it is not hard to spin your own. Some of the functionality is already included in browsers by default (Object.frozen).

[KiaraGrouwstra]

Thanks.
In that case I'll concede a flag + const distinction would probably be more appropriate.

I won't argue against your own use case of explicit per-case opt-in; I think both sound legit.
That said, this may go beyond marking just tuples.

If you'd wanna use Ramda's path function, for one, the type of the path you're passing must be preserved as a tuple of string/number literals for inference to work.
I imagine having to explicitly mark the array and every single element there would feel cumbersome.
If that's solved by checking a compiler flag at the cost of push on const arrays, I could see users in the immutability camp considering that a small price to pay for the considerably more powerful type inference it could potentially enable.

[bradzacher]

I'm not sure a blanket flag would be the best idea, as it would mean you would be severely break from standard JS syntax.

Maybe a new keyword (which compiles to const) would be a good alternative. Eg
pure arr = ['a', 'b'] would mean that the only options available are reads and pure function calls?

You could then also apply this keyword to methods to signify that a function is pure. Which is how the compiler could tell what functions on an object are safe to call for a pure declared variable.

This keyword could be enforced by the compiler, meaning that a function marked with the pure keyword cannot have a body which:
(a) writes to properties on this,
(b) writes to properties on input arguments,
(c) calls functions not marked as pure.

Additionally the compiler could automatically mark methods as pure if they don't violate any of the above rules.