[IDEA] Define operators only in classes

[FrameMuse]

Description

There are some problems with this proposal such as "unpredictability" and a ton of others.
A probable solution is using classes because it's rarely needed to have custom operators on plain objects (const myObject = { ... }), as far as I can understand it, it's oriented on class object to result back with the same class object like it's done in the example of Vector.

Solution

Define (or override) operators only in classes

class Vector {
  constructor(
    public x: number,
    public y: number
  ) { }
  
  public operator -(a: Vector, b: Vector): Vector {
    return new Vector(a.x + b.x, a.y + b.y)
  }
  
  public operator ==(a: Vector, b: Vector): Vector {
    return a.x === b.x && a.y === b.y
  }

By this, operators can only be defined within a certain class and not on plain object. And make it exist only in TypeScript scope (for now) for people who may want to test it or play with it, giving also advantages to library creators and other proposals like Temporal.
For example

Temporal.Now.Instant() + Temporal.Instant.Hour * 3 // Returning `Temporal.Instant` with current time plus 3 hours

Or

class Price {
  constructor(public value: number) { }
  public format(): string { ... }
  
  public operator +(a: Price, b: Price): Price {
    return new price(a.value + b.value)
  }
}

const myPrice1 = new Price(100)
const myPrice2 = new Price(77)

(myPrice1 + myPrice2).format()

Eventually

• It will compile into a status quo javascript, so no syntax or logic will be touched (for now) but give opportunities for testers and make more people know about this proposal.
• It can't be overriden from outside because it does not actually exist in runtime.
• The hints in typescript IDE will show what specific operators on classes do and maybe change colors of them to highlight that the behaviour is changed.

And probably, making this proposal advance a bit already.

[Haringat]

@FrameMuse I get behind your point about operators for plain objects causing a lot of ambiguity (some of them I put to discussion in #55) but making this Typescript-first would go not only against the purpose of TC39 (which is to define ECMAScript, not Typescript) but also against Typescript's goals (which is to only add types to ECMAScript syntax and nothing more).

[FrameMuse]

@Haringat I don't much about decorators but when I was writing this issue I was inspired by it.

Probably, this would be nice if there was proposal about testing features, before they come to javascript, in typescript, because, you know, typescripters actually writting javascript with types :_/\

Excuse me for my complete ignorace in advance.

[Haringat]

@FrameMuse
It is not on me to pardon the failures of man...

On a more serious note, though: TypeScript has a set goal and scope: add types to JavaScript. No more, no less. Expanding on that would create more of that beautiful and totally not maddening mess (/irony) that we have with the first iteration of decorators which made it far enough to work in theory and to be built into and be tested in engines and transpilers (such as TypeScript or babel) but then turned out to be a bad idea and now we have that old thing lying around in every TypeScript version that is deprecated but still there for people to use (and even some big frameworks like Angular or NestJS do) which means that we cannot even remove the old stuff anytime soon.

That would happen to even more things if we just tried out every proposal in TypeScript and babel. Actually babel is a much more suitable "playground" for evaluating features because it is pluggable - something TypeScript also wants to do some day but probably not anytime soon (see microsoft/TypeScript#16607)

But the decorators thing also proves that proposals ARE put into e.g. TypeScript before they land in the JavaScript spec. However, that is one of the last steps in the TC39 process so that a) the proposal is ripe enough that TypeScript & similar do not have to chase specs and change their implementation every few days as the proposal changes and b) their maintainers are not overwhelmed by the creativity of the proposal creators and the resulting number of proposals (out of which many are rejected at sometimes early stages rendering their implementation unnecessary).

[ljharb]

@Haringat to be clear tho, decorators are a feature that TS added way too early, and the costs of that mistake is why the TS team has committed to no longer shipping anything prior to stage 3, iirc.

@FrameMuse thats what stage 2 and 3 are for.

[FrameMuse]

Thank you both @Haringat and @ljharb for the information and details provided. And hence my issue relied on "the way of decorators" and it turned out to be a bad [IDEA] for early stages and TS itself - I'm closing this issue.