Evolving any behavior for local function variables

Search Terms

• evolving callback

Suggestion

When you declare a local variable whose type is implicitly any, it has an opportunity to "evolve" before triggering an implicit any error:

let x = null;  // type is any, but not an error
if (Math.random() < 0.5) x = 'hello';
x;  // type is string | null

My suggestion is to allow a similar behavior for functions whose parameters implicitly have an any type. This is currently an error, but there's nothing wrong with the code:

{
  const mapFn = x => x * x;
  // Parameter 'x' implicitly has an 'any' type. (7006)
  [1, 2, 3].map(mapFn);
}

If x's type were allowed to "evolve" from any to number, this correct code would type check.

Anders doesn't like "spooky action at a distance." But perhaps some limited, self-contained action within a block could solve this problem while avoiding the spookiness?

Use Cases

The loss of contextual types when you factor out a variable is a perennial pain point in TypeScript. See, for example:

• How TypeScript Breaks Referential Transparency
• React+TypeScript Cheatsheet

This is felt most acutely with React components, where factoring out a function often forces you to dig through type declarations for fairly complicated event types. See below.

Examples

The Array.prototype.map example above is one.

Here's an example with a React component. An inline handler requires no explicit types:

function LoggedCell(props: {cellText: string}) {
  return (
    <td onClick={e => {
        e.stopPropagation();
        // do something
      }}>{props.cellText}</td>
  );
}

Factoring out the callback into a local variable produces a no implicit any error:

function LoggedCell(props: {cellText: string}) {
  const clickFn = e => {
    // Parameter 'e' implicitly has an 'any' type.ts(7006)
    e.stopPropagation();
    // .. do something ...
  };

  return (
    <td onClick={clickFn}>{props.cellText}</td>
  );
}

You can dig up the parameter type to fix this, but it's a mouthful:

function MyComponent() {
  const clickFn = (e: React.SyntheticEvent<HTMLTableDataCellElement>) => {
    e.stopPropagation();
    // .. do something ...
  };

  return (<td onClick={clickFn}>Table Cell</td>);
}

There's nothing really wrong with the middle version. I think it should work.

Caveats:

• Would this mean the type checker has to go back and type check the function body? Is that possible? Would that break lots of other things?

• If you used the callback in two places, would its type have to be the union of the two? Evolving any has this behavior, e.g. if you push a number and a string onto an array, its type becomes (number|string)[].

• Is it OK to return the function? Or let its inferred type "escape" in some other way?

• Like the current evolving any, this probably wouldn't work in functions (#35132). So you couldn't use it in a React component that calls map, for example:

  contents.map(cell => <td onClick={clickFn}>{cell}</td>);
  

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code

This would allow some code that triggers a type error now to pass. Not sure if that's what's meant by "breaking." The code that passes would be code that works correctly at runtime.

• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Non sono indicati file di implementazione, test o entry point. Inizia riproducendo gli esempi locali di callback con noImplicitAny abilitato e leggendo il comportamento esistente di evolving-any descritto nell’issue. Il lavoro è completato quando si concordano le regole di inferenza e di escape e si coprono i casi accettati e rifiutati con test del type-checker.