Repository navigation
@overload doesn't check implementation against overload signatures #52367
Description
#51234 introduced a new @overload tag, but it doesn't have the same type-checking rules as TypeScript's overloads.
Namely that we ensure that for each overload, the implementation signature is assignable to that overload, allowing the return type to be bidirectionally assignable.
If we want the same results in checkJs, then the following should error:
// @ts-check
/**
* @overload
* @param {number} x
* @returns {number}
*/
/**
* @param {string} x
* @returns {string}
*/
function wut(x) {
return String(x);
}
wut(123).toFixed(2);
Activity
RyanCavanaugh commentedon Jan 23, 2023
Is this desirable? I feel like our implementation/overload checking logic is so full of holes that it's not clear that JS Doc users would really benefit from it.
DanielRosenwasser commentedon Jan 23, 2023
Do you think JSDoc users want stricter checking or looser checking? If stricter, we can tighten the rules.