Part of the reason we've declined to do Applicative so far is that mapping a list of functions over a single argument is only one possibly usage of ap - in general, it lets you combine list of functions and multiple args, invoking the combination of all of them. For example, giving [plus, mul], [1, 2], and [30, 40], aping these together would give [plus(1, 30), plus(1, 40), plus(2, 30), plus(2, 40), mul(1, 30), mul(1, 40), mul(2, 30), mul(2, 60)] (aka [31, 41, 32, 42, 30, 40, 60, 80] - in general, it takes an list of functions and some number of lists of arguments, inverts them into a list of (func, arg1, arg2, ...) tuples, and invokes each of those tuples, returning the final list of results. (And of course, by "lists" here I mean any Applicative.)
If you limit this purely to a list of functions and a single argument, then the benefits largely disappear. As you note, it's just a slightly shorter way to spell an existing .map() expression at that point.
@tabatkins Thanks for the extra insight. fwiw my primary use case is using one arg and destructuring the returned values out to different variables, associated with the result of each function.
In most cases, I have a number of functions that all expect the same complex type for their parameter(s). One common of this would be a user object, for which you might have functions to calculate the user's full name, age, obfuscated card number, etc.
One particular use case I had involved several helper functions I had which I called repeatedly when setting up and managing an active chess board.
@rbuckton Could you please indicate if I got the syntax right here? If that is accepted, I will rescind this proposal, but I was encouraged in my functional destructuring proposal to propose ap directly as array methods might be easier to justify.
If the syntax is wrong and would actually need to be [β¦] = Array(10).fill(piece), then I might admittedly still see significant value in an ap method, or some other way to functionally destructure from a single argument.
@rbuckton Could you please indicate if I got the syntax right here? If that is accepted, I will rescind this proposal, but I was encouraged in my functional destructuring proposal to propose ap directly as array methods might be easier to justify.
Extractors do not quite work this way. First, the syntax const [ /*whatever*/ ] = piece implies that piece must be an iterable. Second, each of the functions you're using must return an array, i.e.:
(piece) => [piece.dataset.pieceName]
// etc.
This is generally far less efficient than just writing:
About extensions proposal, the extensions proposal does not include destructuring because I was not sure whether it's a good idea that time, especially it only relate to extension getter, seems not need to include it in the core proposal.
However, this is largely similar to the GitHub - tc39/proposal-destructuring-private: A proposal integrate private fields and destructuring proposal (which allows destructuring of private fields). So if the extensions proposal advances to the next stage, we could also have a corresponding proposal-destructuring-extension-getter. Alternatively, if by then the proposal-destructuring-private has already reached stage 3 or stage 4, it could be directly integrated into the extensions proposal.