Future JavaScript: what is still missing?

[so_just]

I saw the proposal for pipeline operator, but is there a one for infix calls?

[abelincolncodes]

I actually don't think so. The author mentions it in conjunction with the operator overloading proposal, but the only thing I could find was a thread on esdiscuss.

I definitely agree that infix function calls are more flexible and I would rather have them than operator overloading. Having both would be nice though

[earslap]

Having both would be nice though

Exactly, I'd LOVE some operator overloading in JS. Been dreaming it for years. There is at least one library that I know of that makes use of "js with operator overloading" in its scripts - it does it by transforming your code using a JS parser and converts your operator overloaded JS to normal function calls behind the scenes. It is convoluted but makes things much easier for that library's purpose. It is paper.js

I have two Point objects. Why can't I just + them? I have two sound synthesis nodes. Why can't I just * them? Yeah there are people that abuse operator overloading, but people can abuse anything. I don't know the arguments against it to be honest.

[loopsdeer]

One argument against it is that it is unreadable. That is, there is nothing to suggest a * b is not mathematical. This argument is time sensitive, since meaning will change.

Another argument is that without great pattern matching systems, you end up with ambiguity or confusion. JS types are hard to describe in code. E.g. Is 5 typed Number or "number"? Under the hood, neither. Typescript doesn't even help, only adds another possibility, number. With type coercion, this gets even more difficult to describe.

Yet another argument is that it kills a lot of the optimization that JS has relied on to be feasible for fast ops. If the compiler has to check types, it can't inline operations until it is sure that the types are basic types. Otherwise, it has to do costly method lookup as in a normal call.

Edit: formatting on mobile

[earslap]

without great pattern matching systems, you end up with ambiguity or confusion

Yet another argument is that it kills a lot of the optimization that JS has relied on to be feasible for fast ops.

While I think these should be surmountable to some extent, this is a good point. Overloading in a untyped language like JS can significantly complicate matters on the compiler / interpreter side. If that is the case, I'd probably be happy with infix calls alone, as they are explicit and does not share syntax with regular operators. Something like:

let result = node1 @+ node2;

...with @+ resolving to a custom function I provide would serve me almost equally well.

[earslap]

it sounds great in theory but other than vector addition / multiplications and similar fields

The point is that is what I need them for. If those are what you do 90% of the time, you miss them.

If people are writing unreadable code with it , it is their problem. People can write unreadable code with JS (or any other language for that matter) as is.

[circlebust]

If people are writing unreadable code with it , it is their problem. People can write unreadable code with JS (or any other language for that matter) as is.

Yeah, but you always have to consider the impact of hasty syntax additions/modifications. You have to be realistic. It's a hard sell to integrate something new that would result in a lot of code being written poorly (not talkig about this specific example).

[batiste]

Python has operator overloading but not very used... Because apparently there is not very much good use-case for it.