Cannot invoke an expression whose type lacks a call signature when --strictNullChecks enabled

[punmechanic]

TypeScript Version: 2.1.5 and 2.1.6

Code

With --strictNullChecks enabled.

interface Foo {
  foo(): void
}

class A<P extends Partial<Foo>> {
  props: Readonly<P>
  doSomething() {
    this.props.foo && this.props.foo()
  }
}

Expected behavior:
I should be able to invoke this.props.foo() as I have proven to the typechecker that this.props.foo is not undefined† and it cannot be any other value.

Actual behavior:
Throws the following compiler error:

test.ts(12,23): error TS2349: Cannot invoke an expression whose type lacks a call signature. Type '(() => void) | undefined' has no compatible call signatures.

This issue was introduced in TypeScript 2.1.5 and is present in TypeScript 2.1.6. The above code compiles just fine in TypeScript 2.1.4.

This issue does not present itself if A.props is P instead of Readonly<P>. You are unable to circumvent this error by using !, so this is probably not an error with null checking, despite it only being present while strictNullChecks are enabled.

Without wanting to make myself sound more intelligent than I am, I suspect the issue has something to do with the interaction between readonly and a potentially undefined value.

† Technically this code proves to the typechecker that this.props.foo is not falsey, however the same issue is found when comparing this.props.foo explicitly to undefined or doing typeof this.props.foo === 'function'.

[mhegazy]

Since there is a generic type, the type of this.props.foo is P["foo"]. and currently narrowing does not work on generic types. what we need is a new type operator, call it !, so that the type of this.props.foo after the check would be P["foo"]!, which is guaranteed to not be undefined or null.

[punmechanic]

Hey @mhegazy, regardless of discussions of feature implementations - I submitted this as a bug because it's a regression; this was working perfectly fine in TS 2.1.4. What has changed?

I'd also be surprised if we would want a new operator for this; this seems a very intuitive type deduction for TypeScript to be able to make. I wouldn't want to have to circumvent the type checker by forcing it to ignore the possibility of something being undefined.

In general I try to tell the compiler what something because I'm usually wrong, so I would be pretty upset if the answer to this was this.props.foo()! :(

Also worth noting that the above code works perfectly fine without the Readonly<T> type.

[JabX]

I'm pretty sure that I have the same problem with the newest React definitions that define this.props as Readonly<P>. A lot of my code breaks because narrowing from P["foo"] doesn't work and I'm not ready to rewrite some perfectly valid code, so I'm sticking with the older definitions where this.props is mutable.

[punmechanic]

@JabX Yes, this is where I got the issue from. I just simplified the example into something that was, well, simpler.

[vegansk]

So, is this the only workaround or it can be prettier?

export interface FormBaseProps {
  onInitForm?: (f: FormBase<any, any>) => any
  onDestroyForm?: (f: FormBase<any, any>) => any
}
abstract class FormBase<T extends FormBaseProps, S> extends Component<T, S> {
  componentWillMount() {
    this.props.onInitForm && (this.props as FormBaseProps).onInitForm!(this)
  }

  componentDidUnmount() {
    this.props.onDestroyForm && (this.props as FormBaseProps).onDestroyForm!(this)
  }
}