Not assignable Type

Compiler Options:

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Input:

const message: string = 'hello world';
console.log(message);

const b = message ? message : undefined;
const c = message ? message : undefined;

const a: [string, undefined] | [undefined, string] | [string, string] | [undefined, string] = [b, c];

Output:

"use strict";
const message = 'hello world';
console.log(message);
const b = message ? message : undefined;
const c = message ? message : undefined;
const a = [b, c];

To me, Type [string | undefined, string | undefined] is assignable to type [string, undefined] | [undefined, string] | [string, string] | [undefined, undefined].

Except, it isn't.

declare const a : [
  string | undefined, 
  string | undefined
];
//Assume this is okay
const b : (
  | [string, undefined] 
  | [undefined, string] 
  | [string, string] 
  | [undefined, undefined]
) = a;

if (b[0] == undefined) {
  //b is now narrowed to 
  //[undefined, string] | [undefined, undefined] 
  a[0] = "hello, world"; //this is allowed
  console.log(b[0]); //"hello, world"
}

This feels like a bug. As per this comment, recent changes to discriminant assignment should probably handle this. For example, this works:

const message: string = 'hello world';
console.log(message);

const b = message ? message : undefined;
const c = message ? message : undefined;

interface Pair<L, R> {
    0: L,
    1: R;
}

const a: Pair<string, undefined> | Pair<undefined, undefined> | Pair<string, string> | Pair<undefined, string> = [b, c];

Sounds like a bad idea to allow the assignment, since it's unsound.

Somewhat related to #33205

I keep telling everyone assignments like these aren't sound and shouldn't be allowed but it's like I'm talking to the wind >.>
And everyone just goes on like I haven't said anything

I keep telling everyone assignments like these aren't sound and shouldn't be allowed but it's like I'm talking to the wind >.>
And everyone just goes on like I haven't said anything

TypeScript has always allowed covariant references, much like many other languages, which are known to be unsound in the presence of mutation and aliasing.

Except, in this case, it's a contravariant assigment, isn't it?

We're trying to assign string|undefined to string, or string|undefined to undefined

declare const a: (string | undefined)[];
//Fails because contravariant assignment
const b: string[] = a;

declare const c: (string | undefined)[];
//Fails because contravariant assignment
const d: undefined[] = c;

declare const e: (string | undefined)[];
//Fails because contravariant assignment
const f: (string[]) | (undefined[]) = e;

declare const g: [string | undefined];
//Fails because contravariant assignment
const h: [string] = g;

declare const i: [string | undefined];
//Fails because contravariant assignment
const j: [undefined] = i;

declare const k: [string | undefined];
//Fails because contravariant assignment
const l: [string]|[undefined] = k;

Playground

Also related,

declare const a : [
  string | undefined, 
  string | undefined
];

//This satisfies the type checker
const b : (
  | [string, undefined] 
  | [undefined, string] 
  | [string, string] 
  | [undefined, undefined]
) = (
  a[0] == undefined ?
  (
    a[1] == undefined ?
    [a[0], a[1]] :
    [a[0], a[1]]
  ) :
  (
    a[1] == undefined ?
    [a[0], a[1]] :
    [a[0], a[1]]
  )
);

//Would be nice if this satisfied the type checker
//New object literal should be okay
const c : (
  | [string, undefined] 
  | [undefined, string] 
  | [string, string] 
  | [undefined, undefined]
) = (
  [a[0], a[1]]
);

//Would be nice if this satisfied the type checker
//New object literal should be okay
const d : (
  | [string, undefined] 
  | [undefined, string] 
  | [string, string] 
  | [undefined, undefined]
) = (
  [...a]
);

Playground

Syntax directed subtyping algorithms commonly suffer from the problem that they can't prove this relation using the normal decomposition rules, exactly because you decompose into things that try to related string | undefined to string.

If mutations are disallowed, I agree with you about the former being a subset of the latter.
If mutations are allowed, then I disagree.

But I guess TS pretends mutations don't happen.

Given a value x of type [string|undefined, string|undefined], you can always change the value of x[0] to a string, or change it to undefined.

But,

Given a value y of type [string, undefined], you cannot change y[0] to undefined.
Given a value y of type [undefined, string], you cannot change y[0] to string.
Given a value y of type [string, string], you cannot change y[0] to undefined.
Given a value y of type [undefined, undefined], you cannot change y[0] to string.

So, I probably should not consider mutations, since TS pretends they don't happen (in general), but it's hard for me to do so =x

Ron Buckton (@rbuckton)

Ron Buckton (@rbuckton) n.b. there's a typo (missing the [undefined, undefined] case in the OP) but this looks like a case that should have been handled by your PR to look for matching unions

It looks like this was fixed by #39393, and has been working since 4.0.

Navigation Menu

Repository navigation

Not assignable Type #34967

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Not assignable Type #34967

Description

Activity

AnyhowStep commented on Nov 7, 2019

jack-williams commented on Nov 7, 2019

AnyhowStep commented on Nov 7, 2019

jack-williams commented on Nov 7, 2019

AnyhowStep commented on Nov 7, 2019

jack-williams commented on Nov 7, 2019

AnyhowStep commented on Nov 7, 2019

RyanCavanaugh commented on Nov 8, 2019

rbuckton commented on Dec 16, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions