(Proposal) syntax for contextual typing of a function declaration

[Jessidhia]

Currently, it is possible to give a function a contextual type if it is a function expression. This is often used by callback types, and by certain interface types that add properties, or specify the parameter types / return type of a function.

A common use, in the declaration case, is React.SFC:

interface Props {
  propName?: string
}
const Component: React.SFC<Props> = props => <div>{props.propName!}</div>
Component.defaultProps = { propName: 'propName' }

In the snippet above, props is contextually typed, and the function is only allowed to return a React.Element or null. The function object also has several keys added to it, most notably defaultProps, displayName and propTypes.

However, there is no code reason for why Component needs to be a function expression. It could as well be a function declaration. However, making it a function declaration prevents it from being typed as React.SFC.

Not being able to give it a type requires that all parameters have the types manually written, and also prevents attaching the extra property keys such as defaultProps. It will also not validate the function's return type -- you will instead get an error when you attempt to use the function if it happens to be incompatible.

The idea here is to have a way to tell the compiler what the "contextual type" of a function declaration should be.

One possible syntax could be appropriating the implements keyword used for class:

interface Props {
  propName?: string
}
Component.defaultProps = { propName: 'propName' }
function Component (props) implements React.SFC<Props> {
  return <div>{props.propName!}</div>
}

This would make it so Component uses React.SFC<Props> type as its type, similar to if it was a function expression that has a context given to it. This should have no effect on code emit and can simply be stripped on emit; similarly to the class implements clause.

In more generic terms,

function FunctionName (...ArgumentList) implements TypeExpression FunctionBody

should behave similarly to

var FunctionName: TypeExpression = function (...ArgumentList) FunctionBody

but be an actual hoisted function declaration.

---

Having a way of specifying the type like this also could make for easier refactoring of callbacks -- when extracting a callback from being given as an expression to being a named declaration, you often have to go to the type declaration and copy&paste the signature types to the extracted declaration.

With something like the proposed implements, you will still need to add a type, but it will only be the original context type; which then removes the need of explicitly giving types to each argument and the return type.

[MattiasMartens]

@RyanCavanaugh directed me here because I proposed something that depends on this functionality. My proposal used this alternative syntax:

<TypeExpression> function FunctionName (...ArgumentList) FunctionBody

Am I correct that either syntax would satisfy the functional requirements without introducing ambiguity? If so, I wanted to suggest the above one here because it achieves the same thing while saving an extra keyword (I also personally feel that implements would be confusing to borrow from the context of classes and use to describe functions, but that's just a matter of taste).

Either way, I wanted to chime in and say this would be a great quality-of-life improvement for me. I keep instinctively wanting to use type-checking in this way in my projects. I would like to do it without resorting to arrow functions (which costs you hoisting, and is stylistically a bad choice for describing a big function) or assigning a function declaration to a variable (which requires you to name the function twice—if you want to hold on to hoisting—and which looks really un-Javascripty in general).

[jekh]

I've been searching for ways to type function declarations and found this issue, along with a couple others. This issue is older, but #22063 seems to have a bit more traction. If these issues are the same, could we close this in favor of that, and hopefully encourage the thumbs-uppers here to migrate there?