(Proposal) syntax for contextual typing of a function declaration

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.

Start by comparing the proposed function-declaration syntax with the existing function-expression contextual-typing behavior described in the issue. Determine the parser, checker, emit, and test areas that would need coverage; done means the syntax provides the stated contextual parameter and return typing, supports function properties, preserves hoisting, and emits no extra code.