If you use setData with Array.prototype.map, it makes it harder to add an (optional) second argument to setData without breaking .map(setData); whereas .map(d => setData(d)) would work just as well, always passing a single argument to setData.
And using .then(parseInt) will make it harder for TC39 to possibly add a second argument to the ifFulfilled callback without breaking existing websites; whereas .then(d => parseInt(d)) would continue to work just as well, ignoring the second argument.
Using the function directly as the callback only works if it's been designed for that exact usage only.
Given all that, one should use d => setData(d) as rule of thumb, making it explicit which arguments are expected and used.
parseInt
is the classic example... in this case the extra index passed intoparseInt
... forsetData()
it should be ok IMHOIf you use
setData
withArray.prototype.map
, it makes it harder to add an (optional) second argument tosetData
without breaking.map(setData)
; whereas.map(d => setData(d))
would work just as well, always passing a single argument tosetData
.And using
.then(parseInt)
will make it harder for TC39 to possibly add a second argument to the ifFulfilled callback without breaking existing websites; whereas.then(d => parseInt(d))
would continue to work just as well, ignoring the second argument.Using the function directly as the callback only works if it's been designed for that exact usage only.
Given all that, one should use
d => setData(d)
as rule of thumb, making it explicit which arguments are expected and used.I guess that can make sense. When I first looked at some code that was like
I just thought it was kind of cool. I guess maybe just as something we are aware of.