Add support for explicitly indicating that a function's return type is inferred.

UselessPickles commented 6 years ago

Search Terms

explicit infer return type

Suggestion

Add support for a special infer type that can be used to explicitly indicate that the return type of a function should be inferred from its implementation.

The presence of an explicit infer return type for a function (or arrow function) would have identical observable behavior as if the return type wasn't specified: the return type is inferred from the implementation.

The difference is that the function now technically has a return type specified to indicate that the developer explicitly made a decision to allow the return type to be inferred, rather than simply forgetting to think about what the return type should be.

Use Cases

In a project with strict/explicit code style, it is desirable in general to use a linting rule that requires all functions to have a return type specified (The tslint "typedef" rule for "call-signature", for example: https://palantir.github.io/tslint/rules/typedef/).

There are, however, some situations where the return type of a function is a complex type (involving generics, etc.), such that the return type is more naturally inferred from the implementation of the method, as opposed to it being natural to know the intended return type ahead of time.

In such situations, it would be nice to have the option to explicitly indicate the intent for the compiler to infer the return type of the function. This would both clearly communicate this explicit intent to other developers reading the code, and could be used to satisfy code style and linting rules that require functions to have a return type specified.

Why not just disable the linting rule on a case-by-case basis?

Yes, tslint's support of line-level rule disabling could be used to temporarily disable the linting rule and allow you to omit the return type in such situations. But I feel that language-level support for an explicit infer return type would be much more powerfully clear and expressive. It is especially worthwhile if it is fairly low effort/risk to implement.

Additionally, there is not enough granularity to disable the "typedef" rule ONLY for the "call-signature" context. Disabling "typedef" on that line would also disable checks for parameter types in the signature, which is undesirable.

Examples

A simple example is helper methods for unit tests that use enzyme. Let's say you have a custom React component named MyButtonComponent, and you would like a helper function to find the "close" button within some other outer component:

import { ReactWrapper } from "enzyme";
import { MyButtonComponent } from "./MyButtonComponent";

function findCloseButton(wrapper: ReactWrapper): infer {
    return wrapper.find(MyButtonComponent).filter(".close-button");
}

In this case, the line return wrapper.find(MyButtonComponent).filter(".close-button") returns a strictly typed ReactWrapper<P> type where P is the Props type of the MyButtonComponent component, which allows type-safe access to the current values of the component's props via ReactWrapper's props() method .

Manually writing out the correct return type of the helper function above would be quite tedious and provide very little benefit. Especially if the Props interface for MyButtonComponent is not readily available either because it is not exported, or because MyButtonComponent was created by a complex generic higher order component (HOC). The effort of correctly writing out the return type outweighs its benefits in a situation like this.

Inferring implicit `any`

In the following examples, there is no implementation to infer the return type from:

declare function foo(a: number): infer;

interface Bar {
    bar(b: string): infer;
}

The infer type is actually quite useless here and is guaranteed to be an implicit any type. Perhaps it would make sense to ONLY allow the infer type in contexts where there is something to infer from? If so, then the above examples would be compiler errors because there is nothing to infer from.

Another reasonable option may be to allow it to infer an implicit any type in such a way that will fail to compile when using the --noImplicitAny compiler option. This option is a bit less direct, but perfectly acceptable if it is the most "natural" and low-risk/effort option based on the current structure of code.

Partially Inferred Types

An expansion on this idea would be partially inferred return types:

function foo(value: number): Promise<infer> {
    // return value must be assignable to Promise<any>
    // return type is inferred to be Promise<number>
    return Promise.resolve(value);
}

interface Pair<A, B> {
    a: A;
    b: B
}

function bar(value: number): Pair<infer, infer> {
    // return value must be assignable to Pair<any, any>
    // return type is inferred to be Pair<number, boolean>
    return {
        a: value,
        b: value % 2 === 0
    };
}

This would provide a nice blend of compile time validation that you are returning something in the basic format that you intend, but let the compiler infer complicated parts of the type that are not worth the effort of manually constructing/writing.

Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

RyanCavanaugh commented 6 years ago

What will we do when TSLint adds a rule that bans : infer ? 🤔

UselessPickles commented 6 years ago

A TSLint rule that bans : infer would have no impact on the decision to support : infer in the compiler, because users of TSLint can choose which rules to enable/disable. That would actually provide good flexibility. Let's imagine a new rule called "no-infer-return-type" is added. You really have 3 levels of "strictness" you can enforce on function signatures:

Disable "typedef" rule for "call-signature" if you want to allow implicitly inferred return types in your project.
Enable "typedef" rule for "call-signature" and "no-infer-return-type" if you want to force explicit non-inferred return types in your project.
Enable "typedef" rule for "call-signature" and DISABLE "no-infer-return-type" if you want to force explicit return types in your project, but still allow : infer.

nmain commented 6 years ago

You could also explicitly indicate your intent to use an inferred return type by using // tslint:disable-next-line typedef, and then no new TS changes would be needed.

UselessPickles commented 6 years ago

@nmain yes, I acknowledged this already.

Yes, tslint's support of line-level rule disabling could be used to temporarily disable the linting rule and allow you to omit the return type in such situations. But I feel that language-level support for an explicit infer return type would be much more powerfully clear and expressive. It is especially worthwhile if it is fairly low effort/risk to implement.

Additionally, there is not enough granularity to disable the "typedef" rule ONLY for the "call-signature" context. Disabling "typedef" on that line would also disable checks for parameter types in the signature, which is undesirable.

edit: updated the original suggestion to clarify this

UselessPickles commented 6 years ago

(EDIT: Added this to the main issue comment)

An expansion on this idea would be partially inferred return types:

function foo(value: number): Promise<infer> {
    // return value must be assignable to Promise<any>
    // return type is inferred to be Promise<number>
    return Promise.resolve(value);
}

interface Pair<A, B> {
    a: A;
    b: B
}

function bar(value: number): Pair<infer, infer> {
    // return value must be assignable to Pair<any, any>
    // return type is inferred to be Pair<number, boolean>
    return {
        a: value,
        b: value % 2 === 0
    };
}

This would provide a nice blend of compile time validation that you are returning something in the basic format that you intend, but let the compiler infer complicated parts of the type that are not worth the effort of manually constructing/writing.

UselessPickles commented 6 years ago

Some follow-up thoughts on my previous comment...

I think it should be fairly easy to implement partially inferred return types. The basic concept is:

If infer exists anywhere within the return type, then infer the return type of the function.
Validate that the inferred return type is assignable to the specified return type:
- Create a temporary "expected" return type by replacing all infers with any in the specified return type.
- Fail if the inferred return type is not assignable to the temporary "expected" return type.

This generically works for both wholly and partially inferred return types.

microsoft / TypeScript