Activity

1. MartinJohns commented on Mar 2, 2022

   

   Martin Johns (MartinJohns)

   on Mar 2, 2022

   Contributor

   More actions

   I think this is due to: https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#implicit-any-error-raised-for-un-annotated-callback-arguments-with-no-matching-overload-arguments

   Is the first overload really needed? The code will behave the same without it.
2. JoshuaKGoldberg commented on Mar 2, 2022

   

   Josh Ghoulberg 👻 (JoshuaKGoldberg)

   on Mar 2, 2022

   ContributorAuthor

   More actions

   I think the overloads are needed -- it's either them or an overly long and confusing conditional generic type. The test function can either take in an input or return a Promise. Adjusting the snippet a little to look more like the Mocha types [playground link]:

   declare const it: {
       (test: () => Promise<void>): void;
       (test: (done: () => void) => void): void;
   }
   
   it((done) => {
       done();
   });
   
   it(async () => {
       // ...
   });
   
   // @ts-expect-error
   it(async (done) => {
       done();
   });

   I.e. you can't provide an async function that also takes in & calls a done parameter.
3. fatcerberus commented on Mar 2, 2022

   

   Bruce Pascoe (fatcerberus)

   on Mar 2, 2022

   Last edited by fatcerberus

   More actions

   Assuming the inference worked, you wouldn't get the expected error on the third call (the only reason it's an error now is because it's an implicit any, like the first call), because it would still match the second overload, per https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void:

   declare const it: {
       (test: () => Promise<void>): void;
       (test: (done: () => void) => void): void;
   }
   
   it((done: () => void) => {
       done();
   });
   
   it(async () => {
       // ...
   });
   
   it(async (done: () => void) => {
       done();
   });

   Any return type is assignable to a return type of void, including promises. And you couldn't prevent this at runtime either because you have no way to know that the user passed in an async function without actually calling it and observing its return value.
4. JoshuaKGoldberg commented on Mar 2, 2022

   

   Josh Ghoulberg 👻 (JoshuaKGoldberg)

   on Mar 2, 2022

   ContributorAuthor

   More actions

   the only reason it's an error now is because it's an implicit any, like the first call

   Ha, that's fair.

   But I think this issue is still valid, that the becoming an implicit any is an undesirable behavior (dating back a while) because now there's no way to accurately represent the Mocha types.

   👍React with 👍1Reacted by Bruce Pascoe
5. fatcerberus commented on Mar 2, 2022

   

   Bruce Pascoe (fatcerberus)

   on Mar 2, 2022

   Last edited by fatcerberus

   More actions

   A bit of a tangent but () => void accepting any return type is usually desirable (see FAQ link above), but I do sometimes wish we could write () => undefined for the few cases where you really want to exclude value returns and not then be forced to write an explicit return undefined;.
6. Ryan Cavanaugh (RyanCavanaugh)

   added

   Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.This issue needs a plan that clarifies the finer details of how it could be implemented.

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   on Mar 3, 2022
7. RyanCavanaugh commented on Mar 3, 2022

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Mar 3, 2022

   Member

   More actions

   I'm not quite sure what can be done here. Overload resolution behavior is extremely baked-in and it's going to be tough to change it. PRs that don't break other stuff are welcome 😅
8. JoshuaKGoldberg commented on Mar 3, 2022

   

   Josh Ghoulberg 👻 (JoshuaKGoldberg)

   on Mar 3, 2022

   ContributorAuthor

   More actions

   Hmm, now that #29374 is in I was looking forward to making another multi-year pull request. Great...!

   😄React with 😄1Reacted by Martin Johns
9. fatcerberus commented on Mar 3, 2022

   

   Bruce Pascoe (fatcerberus)

   on Mar 3, 2022

   More actions

   Ryan Cavanaugh (@RyanCavanaugh) I thought this issue wasn’t about overload resolution, so much as contextual typing of callback parameters failing in the mere presence of overloads.
10. RyanCavanaugh commented on Mar 3, 2022

    

    Ryan Cavanaugh (RyanCavanaugh)

    on Mar 3, 2022

    Last edited by RyanCavanaugh

    Member

    More actions

    The problem is that we assign a contextual type during overload resolution, and don't have an acceptable way to "undo" that. Prior attempts to fix this have failed for one reason or another.

    See also #11936

    👍React with 👍1Reacted by Bruce Pascoe