Typescript: Why not operator overloading in Typescript?

[ghost]

Hello. Why not operator overloading in Typescript? I can not found discussion about.

[kitsonk]

Can you provide a specific use case of what you are trying to accomplish?

In most of the use cases I can conceive of operator overloading, it would require some sort of run-time emit, which is very anti-pattern for TypeScript.

[ghost]

For example: vector classes.

  var p0 = new Point(0, 0);
  var p1 = new Point(100, 0);
  var p = p0 + p1; //Operator with overload
  var d = 1 +! 2; //Strict operator (not overloaded)

  point.prototype.__add = function(left){
    //overload operator
  }
  point.prototype.__assign = function(left){
    //overload operator
  }
  point.prototype.__get = function(key){
    //overload array op
  }
  point.prototype.__set = function(key, value){
    //overload array op
  }

Alike: https://github.com/kushal-likhi/operator-overloading-js

But with differences:

• Strict operators that can not be overloaded (with "!" postfix).
• Built-in operator overloading, instead of functions with overloading.

a!["name"] = b; //not overloaded
a["name"] = b; //overloaded
a =! b; //not overloaded
a = b; //overloaded
a +=! b; //not overloaded
a += b; //overloaded

[RyanCavanaugh]

See #5407

[gdefraiteur]

I want operator overload in typescript!

i write a fuckin game engine in typescript if there is operator overloading in it.

[nidin]

@gdefraiteur check out TurboScript with operator overload and pointers which compile to WebAssembly. Even better for game engine 😎

[gdefraiteur]

@nidin why not, but the thing is that i like to code with visual studio, and i'm not sure your language is handled in visual studio node project. :/

the interest of typescript for me is that it is usable in such an ide.

[nidin]

@gdefraiteur IDE support can be achieved by developing a small plugins. Between TurboScript was a prototype. Prototype phase ended, now I am working on a detailed language spec. https://github.com/turboscriptlang/spec

[gdefraiteur]

@nidin well, then i hope your project will go well and that you ll make those required plugins. ^^.

[nidin]

@gdefraiteur of course 🙂

[Ytrog]

To add my 2 cents: I would like to be able to define a composition operator for function composition like const composedFunc = f >> g; or a pipe operator like const result = textBox.value |> trim;

[LBLen]

+1

[munsocket]

You can use Proxy in ES6 to overload brasket operator []. Here example. As i know this will work in typescript [too].(https://www.typescriptlang.org/docs/handbook/advanced-types.html).

[GarkGarcia]

I don't actually think deviating from standard _JS_ and implementing _operator overloading_ is a good idea, but here's a thing I haven't heard anyone talk about:

As state in here, one of the problems with _operator overloading_ proposals for _ECMScript_ is the fact that it would _require extensive type checks_, something that could maybe be facilitated by _TS_'s type system.

I don't have a profound enough understanding on the _tsc_ compiler, but I assume it may hold some extra type information that could perhaps make such an implementation feasible.

[GarkGarcia]

@RyanCavanaugh I'd like to make my point in the original discussion about this, which is now locked. Is there be any possibility of it getting unlocked?

[LBLen]

Is that possible to write a custom typescript transform?

[Ivanca]

Can't believe there is not operator overloading in TypeScript, being the best place to support such feature, right now you need to define a special methods to add two instances of anything , the most simple use case is adding {x, y} coordinates.

Currently you have to use a custom method, lets say is called "add":

const a = new Point(1, 2)
const b = new Point(3, 4)
const c = new Point(4, 5)
const result = a.add(b).add(c)

instead of just being way more understandable code such as

const a = new Point(1, 2)
const b = new Point(3, 4)
const c = new Point(4, 5)
const result = a + b + c

[kungfooman]

Yea, there is no reason for not doing it. HaXe e.g. compiles to JavaScript aswell and also supports operator overloading. And so does AssemblyScript, which compiles directly from TypeScript to WebAssembly.

Every game developer will thank the implementator of operator overloading.

It probably isn't even that hard, just some simple recursive ast conversions from a + b to a.add(b) etc. There are quite some examples for that in pure JavaScript and acorn JS parser, e.g. PaperScript.

[MarvinHannott]

@kungfooman, but it isn't that simple. In fact operator overloading with type inference is hard. And as far as I know, TS doesn't use the Hindley-Milner type system. In effect that means that operator overloading would throw away all of TS's guarantees. For operator overloading to be of any use, the type system needs to be sound and capeable of advanced type inference. TS's type system is neither. Maybe that kind of proposal made more sense for Flow, if it weren't for the fact that they also try not to alter JavaScript in any way. But because Flow tries to be sound instead of pracitcal, it has all the problems TS tries to avoid.
Haxe and Dart (just mentioning) require special JS interop (aka wrappers) and have sound type systems (and Haxe is a very good example how to not do operator overloading).
To wrap it up: It isn't possible. And features like that do hurt compiler performance.

Of course there are other dynamic languages that do support operator overloading, namely Python. But they don't have to worry about type safety. Java doesn't have operator overloading because of all those complications (and some other reasons).

[Ivanca]

Why is it hard exactly, I assume is due inheritance and generics?

[MarvinHannott]

@Ivanca, because the compiler has to evaluate the order of execution and must then determine if the types are compatible. And the receiving type might not actually be the one you are expecting. For example, when adding to interface types and the compiler determines in which order they should be added.
But this is all theory, the TS team has clearly stated that they don't want to implement any kind of dependent emit. And although I would love operator overloading, I understand why it might be not practical.
One must also think about compatibility with existing libraries. Many classes do have an add method but they don't intend it to be used as an operator overload. Should we then use some cryptic special function?

[Ivanca]

if A + A always results in A it would be good enough for most use cases, meaning implementing a subset of overloading where all elements must be the exact same type and the result is that same type as well.

The compatibility is the lesser issues of them all, you can just prefix the methods and be done with it, e.g. __typescript_add__, __typescript_sub__