Repository navigation
Arguments expecting callables should describe the full signature of callables #252
Description
Activity
@stof Thanks for reporting and linking the downstream ticket 👍
I think we all agree that adding more specific types for callables would be useful. I'm happy to look into this once time allows, otherwise we're happy to accept PRs.
For the record, this appears to be clearly documented behavior with its BC implications mentioned in the changelog, so this would be more of feature addition or maintenance rather than a bug, see also related tickets #213, #246 and #247.
@clue sure, the upgrade guide does not actually mention anything for the signature of the
$resolvecallback for the API of the promise constructor (even though I totally understand that this change is related to #213, it isn't mentioned anywhere).
And the changelog entry for that change mentionImprove type safety of promises, but this particular change does not provide any type safety given that it is not reported in types...Line 48 in baf9ab5
@clue I started to look at that and I'm struggling with the type of the
$cancellercallback of the promise constructor. It looks like the canceller can actually be called with$resolveand$reject(same than the$resolvercallback), but what would be the expected argument for$resolvethen ? Does it even make sense to call it ?See PR #253 which adds stricter types for all callable arguments.
Spent the better half of the day working on all edge cases and making sure this is fully covered in our tests. I hope this helps! 👍 If so, consider supporting this project, for example by becoming a sponsor ❤️
Reacted by Alex Skrypnyk
composer/composer#11619 is caused by a wrong usage of the
$resolvecallback passed as argument to the$resolvercallable of the Promise constructor. In version 3, it cannot be called without argument anymore.However, as callable signatures are not described in the argument types, static analysis tools are unable to detect the issue.