Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not operator overloading in Typescript? #6936

Closed
ghost opened this issue Feb 6, 2016 · 21 comments
Closed

Why not operator overloading in Typescript? #6936

ghost opened this issue Feb 6, 2016 · 21 comments

Comments

@ghost
Copy link

@ghost ghost commented Feb 6, 2016

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

@kitsonk
Copy link
Contributor

@kitsonk kitsonk commented Feb 6, 2016

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
Copy link
Author

@ghost ghost commented Feb 6, 2016

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
Copy link
Member

@RyanCavanaugh RyanCavanaugh commented Feb 6, 2016

See #5407

@gdefraiteur
Copy link

@gdefraiteur gdefraiteur commented Mar 21, 2017

I want operator overload in typescript!

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

@nidin
Copy link

@nidin nidin commented May 10, 2017

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

@gdefraiteur
Copy link

@gdefraiteur gdefraiteur commented Jul 31, 2017

@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
Copy link

@nidin nidin commented Jul 31, 2017

@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
Copy link

@gdefraiteur gdefraiteur commented Jul 31, 2017

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

@nidin
Copy link

@nidin nidin commented Jul 31, 2017

@gdefraiteur of course 🙂

@Ytrog
Copy link

@Ytrog Ytrog commented Apr 17, 2018

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;

@LinPoLen
Copy link

@LinPoLen LinPoLen commented May 28, 2018

+1

@munrocket
Copy link

@munrocket munrocket commented Jul 28, 2018

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
Copy link

@GarkGarcia GarkGarcia commented Dec 28, 2018

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
Copy link

@GarkGarcia GarkGarcia commented Dec 28, 2018

@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?

@LinPoLen
Copy link

@LinPoLen LinPoLen commented Dec 29, 2018

Is that possible to write a custom typescript transform?

@Ivanca
Copy link

@Ivanca Ivanca commented Jan 3, 2019

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
Copy link

@kungfooman kungfooman commented Jan 5, 2019

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
Copy link

@MarvinHannott MarvinHannott commented Feb 22, 2019

@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
Copy link

@Ivanca Ivanca commented Feb 22, 2019

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

@MarvinHannott
Copy link

@MarvinHannott MarvinHannott commented Feb 22, 2019

@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
Copy link

@Ivanca Ivanca commented Feb 22, 2019

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__

@microsoft microsoft locked as resolved and limited conversation to collaborators Feb 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet