Flow-analysis involving callbacks should consider readonly fields

[benny-medflyt]

I imagine that this surely has been discussed previously but I searched thoroughly and couldn't find anything.

I am using TypeScript 3.8.3, with all of the strict options enabled.

interface A {
    readonly x: number | null;
}

function printNum(num: number): void {
    console.log(num);
}

export function tst(a: A): void {
    if (a.x === null) {
        return;
    }

    printNum(a.x);

    setTimeout(() => {
        printNum(a.x);  // Error: Argument of type 'number | null' is not assignable
                        // to parameter of type 'number'.
    }, 1000);
}

I understand that if the "x" field is a mutable field, then the compiler is correct (it is possible for "x" to change to null at some point in the future). But I have declared it "readonly" and therefore "a.x" will always be non-null in the call to "printNum" and the code is always type-safe.

[MartinJohns]

But I have declared it "readonly" and therefore "a.x" will always be non-null in the call to "printNum" and the code is always type-safe.

But that's not always the case. You could have just as easily have this code:

function changeNum(obj: { x: number | null }): void {
    obj.x = null;
}

changeNum(a);

Making sure this is not the case would involve following all code paths. (#9998)

[benny-medflyt]

Interesting. I tried your changeNum example and you are correct.

I am surprised by this. I would expect typescript to reject the call to changeNum(a) since the type of "a" isn't the same as the type of "obj".

What it is doing is silently converting a {readonly x : number | null} to {x: number | null}. This basically makes the readonly keyword in general useless IMHO, since it can't be relied upon.

[MartinJohns]

#10725 tracks support for deep readonly support. #14909 for support immutable types (they kinda overlap).

[RyanCavanaugh]

readonly also doesn't imply immutability -- you could have a readonly view of a value that someone else has a writeable reference to.

[benny-medflyt]

readonly also doesn't imply immutability -- you could have a readonly view of a value that someone else has a writeable reference to.

Right, but in this case x is a number primitive, so it is truly immutable

[RyanCavanaugh]

The proposed behavior would make this crashing code legal:

function fn() {
   const obj = { x: 10 as number | undefined };
   const objView: Readonly<typeof obj> = obj;
   return {
      clear() {
         obj.x = undefined;
      },
      objView
   };
}

const a = fn();
if (a.objView.x) {
   window.setTimeout(() => {
      console.log(a.objView.x.toExponential());
   });
   a.clear();
}

[benny-medflyt]

Thank you for the example, that makes sense.

I guess I would say that this line should cause an error:

   const objView: Readonly<typeof obj> = obj;

I understand that TypeScript has already decided that this is the way things should work. I would just like to voice my wish for a future where we can have an option for working with immutable types and values in TypeScript in a simple, intuitive and ergonomic fashion. I will be following #14909 and hope that progress is made.

[RyanCavanaugh]

I think it should be unsurprising that Readonly creates a readonly thing instead of an immutable thing, because immutability and readonlyness are different. The size of a Map is readonly (you cannot set it) but it is not immutable (adding an entry to the map will change it). There are many other analogues to this; if you had some C#-like DateTime thing with a Now property, a ReadOnly<typeof DateTime> should be a no-op, not something that gives you back an "immutable" thing with an ever-changing Now property.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.