Object property in anonymous function in typeguard: Should the typeguard work when the object is const and property is readonly?

[dingfengquek]

TypeScript Version: 2.0.0-dev.20160704
Code

const x : { readonly a: string | undefined } = { a: 's' };
if (typeof x.a !== 'undefined') {
    () => x.a.length;
  }

Expected behavior:
x.a.length should be valid, since x.a is in a typeguard, x is constant, and x.a is readonly, and thus value of x.a cannot change even when the function is called at a later time.

Actual behavior:
[ts] Object is possibly 'undefined'.
(property) a: string | undefined

[zpdDG4gta8XKpMCd]

only true for x.a being a primitive (string, number, boolean, null, undefined) won't work for arrays and objects, Date, Refex

[sandersn]

@Aleksey-Bykov what can change with non-primitives? For example,

interface I { 
  p: string | undefined; 
  q: number;
}
const x: { readonly a: I | undefined } = { a: { p: undefined, q: 12 } };
let f: () => number;
if (typeof x.a !== 'undefined') {
  f = () => x.a.q;
}

How can I change x.a to make the property access x.a.q invalid?

[sandersn]

Fix is up for review at #10015.

[weswigham]

@sandersn :

const x = {
  get foo(): {x: number, y: number} | undefined {
    return this._foo;
  },
  setFoo(foo: any) {
    this._foo = foo;
  }
};

x.setFoo({x: 42, y: 42});
if (typeof x.foo !== "undefined") {
  setTimeout(() => console.log(Math.sqrt((x.foo.x ** 2) + (x.foo.y **2)));
}
x.setFoo(undefined);

Since getters with an unpaired setter are readonly, no further annotations are required. readonly isn't the same thing as immutable, and conflating the two could cause issues (beyond the aliasing ones we've already discussed).

On the other hand, it was always possibly to write a getter which deleted its own value on access and pass that around pretending it was a plain old object, thereby invalidating any type guards on it; so maybe getters are just awful and don't really matter.

[ahejlsberg]

I'm not 100% sure about this change. readonly just means that you can't assign to the property, but there is no guarantee that consecutive get operations will return the same value.

[sandersn]

checkIdentifier already uses isReadonlySymbol to decide whether to narrow outside the lambda. Is that incorrect? I guessed that it was allowed because getters were kind of holey and we decided to be less strict (and less correct) in this case.

(as a reminder, isReadonlySymbol includes readonly, const, get-only accessors and enum members).