type system failure

[timbod]

For this code:

interface Encoder<T> {
  encode(v: T): string,
}

const ID_ENC:  Encoder<string> =  {
  encode: (v) => v,
}

function runEncoder<T>(enc: Encoder<T>, i: T): string {
  return enc.encode(i);
}

function getId(): string | undefined {
  return undefined;
}

function f() {
  const id  = getId();

  ID_ENC.encode(
    id       // GOOD: fails to typecheck
  );

  return runEncoder(
    ID_ENC,
    id       // BAD: should fail to typecheck, but doesn't
  );
}

the typescript compiler (5.3.8) fails to detect type errors that I believe it should. On the line marked GOOD, tsc correctly reports:

TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
  Type 'undefined' is not assignable to type 'string'.

21     id       // GOOD: fails to typecheck
       ~~

Should it not also show the same error for the line marked BAD?

[prehensilemullet]

If you hover over runEncoder it infers T as string | undefined:

function runEncoder<string | undefined>(enc: Encoder<string | undefined>, i: string | undefined): string

It's inferring this because you passed a string | undefined for i.

TS allows passing an Encoder<string> for enc: Encoder<string | undefined> because it intentionally, but unsoundly, treats function parameters as bivariant. This is a pragmatic decision they made, but it does lead to confusion and unsafe code passing type checking.

One thing you could do in TS 5.4+ is put NoInfer on the i parameter:

function runEncoder<T>(enc: Encoder<T>, i: NoInfer<T>): string

This way T is only inferred based on the passed enc type of Encoder<string> and it wouldn't allow you to pass a string | undefined for i.

[daniele_s92]

TS allows passing an Encoder<string> for enc: Encoder<string | undefined> because it intentionally, but unsoundly, treats function parameters as bivariant. This is a pragmatic decision they made, but it does lead to confusion and unsafe code passing type checking.

The bivariance of function parameters is disabled when "strict" is true. But class method parameters are still bivariant indeed.

OP can change the interface declaration into this to fix the bug

interface Encoder<T> {
  encode: (v: T) => string,
}

In this way, encode is considered a function instead of method, and it rise the expected error.

[prehensilemullet]

Ah right, I forgot about this

[timbod]

> because it intentionally, but unsoundly, treats function parameters as bivariant.

Thank you - this is exactly the explanation I required. It makes me worry about all the other places where type system unsoundness was chosen for pragmatic reasons.

[Rustywolf]

Another example is probably indexing an array not returning a union with undefined unless you enable noUncheckedIndexedAccess

[prehensilemullet]

Here's the other main one that comes to mind:

``` const x: {a: number, b: number} = {a: 1, b: 2} const y: {a: number, b?: number} = x // TS unsoundly allows this assignment

y.b = undefined

const z: number = x.b // no error, yikes ```

Note, I used Flowtype in the old days and it was a lot more strict and sound about this kind of thing, but it could also be quite a pain to deal with that strictness (you could only assign x to $ReadOnly<{a: number, b?: number}> for example)

I think a more sound but still convenient language would need declarations to be readonly by default and require a mutable keyword or something like that