Idea: just a more simply solution

[stfbd12138]

Idea

if an operator is prefixed or suffixed with a dot, it's interpreted as method invocation:

• In form of a .op b, equivalent to a[Symbol.op](b)
• In form of a op. b, equivalent to b[Symbol.op](a).
• In form of a .op or .op a where op is an unary operator so that a op is currently-allowing syntax, equivalent to a[Symbol.op]()
• In any of the forms, if the operand could not provide the corresponding method, let it fail as if the invocation has no method.

Examples

Given	De-sugar To
a .* b	a[Symbol.asterisk](b, true/* left */)
a *.b	b[Symbol.asterisk](a, false/* left */)
a .=== b	a[Symbol.strictEquals](b, true/* left */)
a !==. b	b[Symbol.notStrictEquals](a, false/* left */)
!.a	a[Symbol.exclaimaion]()
++.a	a[Symbol.plusPlus](true/* isPrefix */)
a.--	a[Symbol.minusMinus](false/* isPrefix */)

interface Vec3 {
  normalize(): Vec3;
  [Symbol.add](other: Vec3): Vec3;
  [Symbol.asterisk](other: Vec3 | number): Vec3;
}

function zoom(origin: Vec3, dir: Vec3, length: number) {
  return origin .+ (dir.normalize() .* length);
}

console.log((1) .+ 1); // Exception: 1[Symbol.add] is not a function

Props and Cons

Props

• Almost zero-overhead, no runtime check.
• Static, can be type-checked.
• Does not affect current codebases.

Cons

• Let me know.

[shaedrich]

Actually, I don't like a . essentially being a shortcut/alias for Symbol. It just doesn't connect to what it's syntactic sugar for in my head. Maybe, another character would be better 🤔

[GregStanton]

@stfbd12138 This seems like a cool idea! Having a . makes it clear that a custom operator is being used.

@shaedrich Can you explain why . is problematic for you? I think . seems nice for a few reasons:

1. Syntax like a .+ b and a .* b is essentially a replacement for APIs like a.plus(b) and a.times(b).
2. A . is writable compared to a character like $, in that no SHIFT key is needed.
3. A . is visually unobtrusive. Compared to $+, for example, .+ looks a lot more like + (while still being visually distinct).

[GregStanton]

@stfbd12138

Can you explain how you're using Symbol here? Please excuse me if I don't yet know enough about this topic. I would've guessed that it might work as follows.

interface Vec3 {
  [Symbol('+')](other: Vec3): Vec3; // (`+`) not [`+`]
}

Then, if v and w are Vec3 objects, v .+ w is sugar for v[Symbol.for('+')](w, true).

Either way, what do you think about just using string keys, rather than Symbol keys? Is it the case that each approach has trade-offs (simplicity vs. robustness), or is one of these simply not viable at all?

[shaedrich]

@shaedrich Can you explain why . is problematic for you? I think . seems nice for a few reasons:

I thought, I tried to do just that. It's just that . doesn't invoke the mental picture of meaning "Symbol" for me. A . is a primarily used as a property access operator, so it's not initially clear that it is used as a shortcut for a variety of different operators here instead.

[GregStanton]

@shaedrich Thanks! I appreciate you explaining your thinking.

The way I'm thinking of it, the . in v .+ w at least reminds us that a property is being accessed, since it's a shorthand for accessing a property of v. In a similar way, v +. w is a shortcut for accessing a property of w. The use of Symbols seems like more of an implementation detail; whether or not objects actually use a Symbol or a string internally, that probably shouldn't leak into the API for the objects that use the feature. But, I haven't thought about this enough, so any corrections would be appreciated.

[FrameMuse]

Indeed, it needs some time to get used to it, but I think . along with operators would mean an "overloading" rather than "Symbol" in a head.

[jhmaster2000]

I'm also not a fan of the choice of . for this and find it unlikely TC39 would go along with it either for a number of reasons:

1. It would probably be a pain to adjust all the syntax rules in the spec to allow for this without causing conflicts elsewhere with how widely used . is already, but I could be wrong about this one.
2. It already overlaps with the existence of the optional chain operator ?., which could lead to confusion for new devs on whether ?. is a custom operator of some kind, since it would look like one.
3. Similarly, this also conflicts with TypeScript's non-null assertion operator, which can take the form !. when used in the middle of a property access chain (eg: maybenullobj !. prop is valid TS, usually not written with spaces but its still valid nonetheless), leading to further confusion and syntax conflict.
4. The idea of making it feel familiar with property access does work nicely with binary operators (a .+ b) but the backwards-esque look of unary operators just looks like another footgun for confusion (+.a), it almost looks like it should be read backwards, plus having to remember on which side of the operator to place the . based on context sounds like a headache too. Reversing them as .+a isn't any better since now it would be a very odd-looking "property access" into seemingly nothing. Overall I don't think adding this much potential for confusion and ambiguity in such a highly used mechanic like property access is a good idea.

As alternatives, how about either [+] or \+? Both of these solve the conflicts of 2 and 3 by not overlapping with any existing syntax and hopefully are simpler to fit into the current syntax rules regarding 1.

The idea behind [+] is to stick to the idea of resembling property access, but in a more explicit and less conflict prone way, and also solves the weirdness of which side to put the ., as it would look the same for unary and binary: a [+] b vs. [+]a.

Alternatively \+ is in anticipation of dislike of [+] being too much extra to type per-operator and visual clutter, it loses the tie-in to property access, but is equally short, also doesn't require Shift to type (I only mention this because it was made as an argument for .), but doesn't collide with any existing syntax given \ cannot be used anywhere outside of strings or as \u for identifiers, u being not an operator. It can also look the same for binary/unary without looking weird: a \+ b vs. \+a.
Semantically it can be thought of as "escaping" the built-in operator behavior to invoke a custom one, at least it makes sense to me.

Realistically I don't have much hopes of TC39 being onboard with any of this either way if I'm being honest but that's my 2 cents on this.

[chriscalo]

I'm likely misunderstanding something, but isn't the whole point of operator overloading that there's no new syntax to be added to the language? The operator syntax stays the exact same:

Decimal("0.1") + Decimal("0.2") === Decimal("0.3")

All that's new is giving developers a way of specifying how to handle each operation:

// straw man
class Decimal {
  [Symbol.add](other) {
    // …
  }

  [Symbol.strictEquals](other) {
    // …
  }
}

[FrameMuse]

@chriscalo That's JavaScript, it's supernatural

[FrameMuse]

@jhmaster2000 I agree, I was having the same idea but another way like {+}, yeah weird. But it could +} and {+ instead of .. Or using | sign, but it's starting to become brain-fuck when it comes to operators with more than 1 sign like |+=.

[jhmaster2000]

I also had thought of {+} but I quickly disliked it for reasons similar to ., its also already too widely used for core building blocks of the language, scopes and objects, I would also be averse to having it be further overloaded in meaning. Besides I can't really come up with any logical reasoning to justify it looking like an operator inside an object literal.

| is already not one but two operators, | and ||, so it has no chance of working.

But yeah I agree on the brainfuck sentiment, hence I find this suggestion unlikely to be followed up by TC39 regardless of the chosen character anyway, but doesn't hurt to workshop.

[GregStanton]

@chriscalo I think the idea is to provide a solution that's similar to operator overloading, in that it allows custom operator behavior, but with less overall complexity (syntactically, it may be more complex, but maybe the overall complexity is lower?).

@FrameMuse @jhmaster2000 What about : as another candidate? Some considerations:

• It may remind us of object properties because of object literal syntax
• It's used in at least some other contexts to indicate left or right, e.g. in Markdown tables
• The only operator it's currently used with (I think) is the conditional (ternary) operator
• Unlike brackets, it wouldn't cause issues with linters or IDEs that expect paired brackets (we may want to have the extra character only on one side of the operator, to indicate which operand has its method invoked)

It might look a bit confusing, though. I'm not sure. Here are some examples (mostly based on the discussion so far):

a :* b
a *: b
a :=== b
a !==: b
a :+= b
!:a
++:a
a:--

In some contexts (e.g. in math), := can be used to mean "define," but assigning a value is similar to providing a definition, so I suppose that'd be okay. Also, the colon does require the SHIFT key, but I don't think that's really a problem. I only mentioned it in the beginning in case it might break a tie among candidate characters.

@jhmaster2000 I may be misunderstanding one of your objections, but I think there's a simple rule: the extra character always goes between the operation and the operand on which a method will be invoked. This completely determines where it needs to go for unary operations. For any binary operations in which two placements are possible, I imagine there could be a convention to put the extra character on the left, similar to other coding conventions. Also, being able to place a character on one side to indicate which object will have a method invoked (and which side it's on) could be a feature rather than a bug... but it might take some thought to come up with a good use case. With that in mind, I think : might address your four original concerns, although it might raise some new ones.

[FrameMuse]

@chriscalo Jokes aside, the necessity of extra sign comes from the fact that, as far as I understood, it would have negative affect on existing operators since engine would need to do a check for each operator if it's overloaded or not and bla, bla, bla.

That's why initial proposal is to enable it by making imports with with operators phrase to enable overloading (without extra signs).

However, I think I'm missing something here because this reason seams dumb as we know so many languages that implement operators overloading. Sorry, I'm too lazy to read the whole story about it, if anyone could find all the details and make video (or in text) about to summarize we (and I) could move forward in this. Currently we're going back and forth with it IMHO.

[MillerSvt]

I'm certainly not a genius, but didn't anyone think about Proxy? Proxy can already do some magic, why not add some more?

[stfbd12138]

@stfbd12138

Can you explain how you're using Symbol here? Please excuse me if I don't yet know enough about this topic. I would've guessed that it might work as follows.

interface Vec3 {
[Symbol('+')](other: Vec3): Vec3; // (+) not [+]
}

Then, if v and w are Vec3 objects, v .+ w is sugar for v[Symbol.for('+')](w, true).

Either way, what do you think about just using string keys, rather than Symbol keys? Is it the case that each approach has trade-offs (simplicity vs. robustness), or is one of these simply not viable at all?

I think it'd better not to use pure string key since it may break compatibility. But I agree Symbol.add seems more appropreciated than Symbol['+'].

class Vec3 {
  // Affect current codebase
  add() { }

  // Previous, looks strange
  [Symbol['*']]() {} 

  // Looks better
  [Symbol.add]() {}
}

I have updated my post.