With arrow functions released and class properties likely to be approved soon, this has minimal value and is probably not worth the cost of the extra complexity to the language.
It all has to do with this line: "By providing syntactic sugar for these use cases we will enable a new class of "virtual method" library, which will have usability advantages over the standard adapter patterns in use today."
Essentially, you write functions that provide a certain behavior without being coupled to a specific class, so you can have a 'map' method that is called the same way no matter what you're mapping over.
Right now functional libraries like static-land, ramda, sanctuary, etc. are working hard to provide these functional primitives but it's still painful to write readable code that uses these.
It's also worth pointing out that directly importing methods here is more efficient than importing entire classes if you're not using one of those emerging build systems that does very good tree-shaking.
This is the closest JavaScript is going to get to letting you write your behavior as a suite of functions separately from specific classes—it's like a step removed from typeclasses.
There is nothing that this proposal does that cannot be done today. It brings nothing new to the table aside from operator noise. I hope the committee pushes against these exotic features, like the bind operator or the pipe operator.
> Right now functional libraries like static-land, ramda, sanctuary, etc. are working hard to provide these functional primitives but it's still painful to write readable code that uses these.
No it's not. explicit != painful .
Do people really want to end up with a spec of the size of C++ spec ?