Open UselessPickles opened 6 years ago
What will we do when TSLint adds a rule that bans : infer
? 🤔
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:
: infer
.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.
@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
(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.
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:
infer
exists anywhere within the return type, then infer the return type of the function.infer
s with any
in the specified return type.This generically works for both wholly and partially inferred return types.
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:In this case, the line
return wrapper.find(MyButtonComponent).filter(".close-button")
returns a strictly typedReactWrapper<P>
type whereP
is the Props type of theMyButtonComponent
component, which allows type-safe access to the current values of the component's props viaReactWrapper
'sprops()
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 becauseMyButtonComponent
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:
The
infer
type is actually quite useless here and is guaranteed to be an implicitany
type. Perhaps it would make sense to ONLY allow theinfer
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:
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: