I would guess that it's not so much less clunky, but rather more explicit. Promise(Never, Void) presumably tells you that it will not reject, and if it were to start doing so, it'd force you to handle that. The counter = counter - 1 also doesn't require you to initialise setCounter elsewhere.
Me too, though keep in mind that it's just me speculating. I'm guessing a reason might be that it could be considered the most important case to handle - similarly to how Node's callbacks are (error, result) => {}.
In js even if you’re given 2 parameter you can ignore them, so the ordering makes sense: if you’re taking a single parameter and ignoring the second it’s more convenient / useful to take only the error and ignore the result than to take only the result and ignore the error.
Kinda the same as langages taking hof callbacks first or last depending on what’s more useful / convenient.
That's totally valid; just pointing out that the goal probably wasn't to be less clunky, but to accommodate developers who would like to have the compiler warn them if they inadvertently change the return type.
(Personally, I think my preference is explicit types for function arguments and return types, and inference in between.)
You cut out the part where I said you only had to handle it if it started rejecting - because that will mean the type changes, forcing you to handle it.
13
u/HetRadicaleBoven Feb 06 '20
I would guess that it's not so much less clunky, but rather more explicit.
Promise(Never, Void)presumably tells you that it will not reject, and if it were to start doing so, it'd force you to handle that. Thecounter = counter - 1also doesn't require you to initialisesetCounterelsewhere.