Why isn't there a .= operator? (or ->= etc)

Question

Considering how often we do:

variable = variable + another;
variable = variable - another;
variable = variable * another;
variable = variable / another;
variable = variable & another;
variable = variable | another;
variable = variable ^ another;

we then made the following language shortcuts:

variable += another;
variable -= another;
variable *= another;
variable /= another;
variable &= another;
variable |= another;
variable ^= another;

so, then, considering how often we do this:

variable = variable.different();
// or variable = variable->different();
// or variable = variable::different();

(for instance, stringVar = stringVar.toUpperCase()), why isn't there one of these?

variable .= different();
// or variable ->= different();
// or variable ::= different();

is it a parsing issue? Would it be too hard? Or is there some obvious thing I don't see here?

I'm not asking for opinions, here. I want to know if there's any documented, historic, technical, or other verifiable reasons for why there is no such operator.

Answer 1

IMO, the biggest reason is that identifiers are not first class values in programming languages and "." is not a real operator like + or - are. For example, you can't convert

var foo = variable.bar()

into

var name = bar
var foo = variable.name()

The same way you can convert

var foo = 1 + 10

into

var x = 10
var foo = 1 + x

In more technical terms, in most languages x + y is an expression, while x, x.y and x[i] are identifiers.

Summing up, when using your hypothetical .=, the right hand side needs to be interpreted as a field name, not an expression. This leads to unintuitive results - the following two lines look very similar but do wildly different things.

x += bar() // calls the bar() global function and add its value to x
y .= bar() // calls y's bar() method, and sets `y` to its result.

---

Additionally, as Guy Coder pointed out, when using +, -, etc its guaranteed that the type of the resulting expression is the same as the arguments so += always makes sense. On the other hand, we can have y.bar() return a type different from y, in which case .= bar() would make no sense.

Answer 2

In the situtation: variable += another; you have 2 variables, 1 operator and 1 assignment.

In the situtation: variable ->= different() you have 1 variable, 1 method access operator ( i.e ->), 1 method name that needs to be called and 1 assignment.

When a language's syntactic sugar feature is designed, one important concept to consider is composition, i.e how elegantly you can compose these syntactic sugar based expressions.

In the first example you can create a chain of these operations:

variable *= another_var -= variable += another;

Whereas there is no simple way to do this kind of composition in the second case. Lets say we have the below code:

variable = variable.method1();
another_var = variable.method2(params);

If you try to apply the approach that you suggested, you will get into weird situtation:

another_var .= <what should be here> variable .= method1()

In the method based case there is pattern called "fluent API design". You can use that to express the above code elegantly.

another_var = variable.method1().method2(params);

Hope this helps.

Answer 3

The reason it is not done is because the type of the result may not be the same as the type of the receiving term.

In the examples you gave the result and receiving terms are the same type or it is common to coerce the type of the result into the receiving term type which is common with mathematical operators.

Standard way
Int = Int + Int

Syntactic sugar
Int += Int

Receiving Term  Other Term  Result  
Int             Int         Int  
Float           Int         Float  
Float           Float       Float  

If it is taken that -> means pointer then you would have

Standard way
Name = Person -> Name

Your way
Person ->= Name

Receiving Term  Other Term  Result  
Object          String      String  

So setting an object to a string would either cause the type of the object to become a string which may not be desired or the compiler might throw an exception.

Standard way
Color = Bird -> Color

Your way
Bird ->= Color

Receiving Term  Other Term  Result
Bird            Color       Color

Obviously a bird should not be a color but can have a color.

Answer 4

The simple thing is we rarely found this situation for using like this

 variable = variable.different();
// or variable = variable->different();
// or variable = variable::different();

since we call a function with objects and assign the return value to the variable and normally we never return an object back to the same in old days.

there fore the compiler designer will never think about giving special meaning to the .= or ->=

but if you take the examples of arithmetic operators we will found this may be in every program like tormenting adding etc .

but when the concept of OOP is increased rapidly one need to think about giving such a special meaning..

Answer 5

I would like to build on hugomg with this example from JavaScript:

var foo = variable.bar()

can be rewritten as

var name = "bar";
var foo = variable[name]();

When it comes down to it, . is just as much an operator as +. It's a binary operator who's left side must be an object, and who's right side should be a property name in that object. In ES at least, for property names that don't fit the identifier requirements, there's a different notation that does the same thing.

Further, while x is an identifier and y is also an identifier, x.y is an expression, not significantly different from 1+2 except in how it is carried out. The simple fact that the . operation can be interfered with (via Proxy) is proof that x.y is not simply an identifier.

The real reason why .= is not an operator is simply that it makes code harder to read and understand, even for the engine. Consider this:

function add(a=0, b=0) {
  return a + b;
}

some.preexisting.obj.with.an.add.function .= add(3);

This would be valid code, but confusing as heck. Without the dot in .=, the add function in this example would be called. However, with it, the add function belonging to that ridiculous object would be called. This goes against some basic understandings about the nature of ES function calls. In short, it's just a bad idea.