🔎 Search Terms
NoInfer
brittle inference
object properties
Related issues:
🕗 Version & Regression Information
Tested in 6.0.2 and nightly.
⏯ Playground Link
Playground Link
💻 Code
See playground for the full example.
type fooArgs<T> = {
a: (_: A) => X<T>,
b: Y<NoInfer<T>>
}
function foo<T>(args: fooArgs<T>) {}
foo({
a: (_) => ...,
b: ... // inference of the value given to b is VERY brittle.
});
🙁 Actual behavior
Sometimes, b is inferred before a.
Then, as a is the one used to infer the generic parameter T, the value given to b doesn't have the correct type (because inferred before a).
This is likely due to the fact that the value given to a is a callback with a parameter we didn't specify the type ((_) => ...). Therefore, TS has first to look at fooArgs<T> to infer the callback's parameter type (i.e. the type of _).
Due to that, b is sometime inferred before a has been properly inferred. This behavior depends on the order of the object properties (cf related issue). It is also influenced by other defined properties, and how they are defined. Making the inference quite chaotic.
🙂 Expected behavior
TS should infer NoInfer<T> properties AFTER T properties, in order to prevent such issues.
Additional information about the issue
The fact that the order of the inference changes is quite troublesome, hiding the issue in some cases.
Could be nice to have a kind of tool/flag to detect such kind of potential issues, and to help debugging.
EDIT: A possible workaround:
type fooArgs<T> = {
b: Y<NoInfer<T>>
}
function foo<T>(a: (_: A) => X<T>, args: NoInfer<fooArgs<T>>) {}
foo(
a: (_) => ..., {
b: ...
});
🔎 Search Terms
NoInfer
brittle inference
object properties
Related issues:
🕗 Version & Regression Information
Tested in 6.0.2 and nightly.
⏯ Playground Link
Playground Link
💻 Code
See playground for the full example.
🙁 Actual behavior
Sometimes,
bis inferred beforea.Then, as
ais the one used to infer the generic parameterT, the value given tobdoesn't have the correct type (because inferred beforea).This is likely due to the fact that the value given to
ais a callback with a parameter we didn't specify the type ((_) => ...). Therefore, TS has first to look atfooArgs<T>to infer the callback's parameter type (i.e. the type of_).Due to that,
bis sometime inferred beforeahas been properly inferred. This behavior depends on the order of the object properties (cf related issue). It is also influenced by other defined properties, and how they are defined. Making the inference quite chaotic.🙂 Expected behavior
TS should infer
NoInfer<T>properties AFTERTproperties, in order to prevent such issues.Additional information about the issue
The fact that the order of the inference changes is quite troublesome, hiding the issue in some cases.
Could be nice to have a kind of tool/flag to detect such kind of potential issues, and to help debugging.
EDIT: A possible workaround: