Is +=(or any assignment operators) a method in scala for Int type.
For example,
var x=5
x+=1
Here I am able to use += method only when it is a variable.
I am not able to do,
5+=1
Does scala compiler considers this method as a special case?
Why it is not available in scala.Int class?
There is no += method, it is expanded to x = x + 1 by the compiler. This is detailed in the specification:
6.12.4 Assignment Operators
Let's consider an assignment operator such as += in an infix operation
l += r, where l, r
are expressions. This operation can be re-interpreted as an operation
which corresponds to the assignment
l = l + r
except that the operation's left-hand-side l is evaluated only once.
The re-interpretation occurs if the following two conditions are
fulfilled.
The left-hand-side l does not have a member named +=, and also cannot be converted by an implicit conversion to a value with a member
named +=.
The assignment l = l + r is type-correct. In particular this implies that l refers to a variable or object that can be assigned to,
and that is convertible to a value with a member named +.
Related
Scala only sometimes desugars
a += b
to
a = a + b
but not always. For example, some mutable collections define a += method, where instead it becomes
a.+=(b)
Is this behaviour
entirely determined by whether there is a suitable += method on a? (incl. are there any other examples of this behaviour?)
independent of whether the objects are val or var?
Relevant example
Adapted from Programming in Scala, in
var s = Set("a", "b")
s += "c"
In this case, the second line of code s += "c" is essentially shorthand for:
s = s + "c"
When does a += b become a = a + b in Scala?
When there is no applicable += method, there is an applicable + method and a is assignable (that is, it's a var or there's an a_= method).
Or as the spec puts it:
The re-interpretation occurs if the following two conditions are fulfilled.
The left-hand-side l does not have a member named +=, and also cannot be converted by an implicit conversion to a value with a member named +=.
The assignment l = l + r is type-correct. In particular this implies that l refers to a variable or object that can be assigned to, and that is convertible to a value with a member named +.
Is this behaviour
entirely determined by whether there is a suitable += method on a?
independent of whether the objects are val or var?
Not quite. If there is a suitable += method, it will be called regardless of any other factors (such as a being assignable). But when there isn't, the other factors determine whether it's desugared or you get an error message.
Note that the error message you get is different than the one you'd get from the desugared version: When the criteria for the desugaring don't apply, you get an error message that tells you "+= is not a member of ...", plus an explanation why the desugaring couldn't be applied (such as "receiver is not assignable" or the type error you'd get from a + b if a + b would produce a type error).
In my first answer I was a little hasty, my apologies. After researching a little and after read better the #sepp2k's answer and comment, I came to the conclusion that some classes in Scala implements the += method, and other just the + method, I played a little in With some Scala code and for instance:
//Set, Int, Double, String implements the "+" method,
//and then "+=" is syntactic sugar of a = a + b
var set = Set("a", "b")
set += "c"
var num = 3
num += 2
var str = "43"
str += 5
var l = List()
l += "someString"
// As you mention, MutableList implements "+=" method, and when you do
// mutL += 4, is the same as call the method mutL.+=
var mutL = new mutable.MutableList[Int]
mutL += 4
Just starting out with Scala
var c = 0
c += 1 works
c.+= gives me error: value += is not a member of Int
Where is the += defined?
Section 6.12.4 Assignment Operators of the Scala Language Specification (SLS) explains how such compound assignment operators are desugared:
l ω= r
(where ω is any sequence of operator characters other than <, >, ! and doesn't start with =) gets desugared to
l.ω=(r)
IFF l has a member named ω= or is implicitly convertible to an object that has a member named ω=.
Otherwise, it gets desugared to
l = l.ω(r)
(except l is guaranteed to be only evaluated once), if that typechecks.
Or, to put it more simply: the compiler will first try l.ω=(r) and if that doesn't work, it will try l = l.ω(r).
This allows something like += to work like it does in other languages but still be overridden to do something different.
Actually, the code you've described does work.
scala> var c = 4
c: Int = 4
scala> c.+=(2) // no output because assignment is not an expression
scala> c
res1: Int = 6
I suspect (but can't say for sure) that it can't be found in the library because the compiler de-surgars (rewrites) it to c = c.+(1), which is in the library.
I'm reading Programming in Scala by M. Odersky and now I'm trying to understand the meaning of operators. As far as I can see, any operator in Scala is just a method. Consider the following example:
class OperatorTest(var a : Int) {
def +(ot: OperatorTest): OperatorTest = {
val retVal = OperatorTest(0);
retVal.a = a + ot.a;
println("=")
return retVal;
}
}
object OperatorTest {
def apply(a: Int) = new OperatorTest(a);
}
I this case we have only + operator defined in this class. And if we type something like this:
var ot = OperatorTest(10);
var ot2 = OperatorTest(20);
ot += ot2;
println(ot.a);
then
=+
30
will be the output. So I'd assume that for each class (or type?) in Scala we have += operator defined for it, as a += b iff a = a + b. But since every operator is just a method, where the += operator defined? Maybe there is some class (like Object in Java) containing all the defenitions for such operators and so forth.
I looked at AnyRef in hoping to find, but couldn't.
+= and similar operators are desugared by the compiler in case there is a + defined and no += is defined. (Similarly works for other operators too.) Check the Scala Language Specification (6.12.4):
Assignment operators are treated specially in that they can be
expanded to assignments if no other interpretation is valid.
Let's consider an assignment operator such as += in an infix operation
l += r, where l, r are expressions. This operation can be
re-interpreted as an operation which corresponds to the assignment
l = l + r except that the operation's left-hand-side l is evaluated
only once.
The re-interpretation occurs if the following two conditions are
fulfilled.
The left-hand-side l does not have a member named +=, and also cannot
be converted by an implicit conversion to a value with a member named
+=. The assignment l = l + r is type-correct. In particular this implies that l refers to a variable or object that can be assigned to,
and that is convertible to a value with a member named +.
How is the ++= being evaluated in the code below? The ++= operator is being applied to a class that is explicitly defined as an immutable list, which does not have the ++= operator. x ++= y appears to have the same behavior as x = x ++ y, but I cannot find where this behavior is coming form. What is happening here? (and where is it documented?)
object ListConcatenation extends App {
var list = scala.collection.immutable.List[Int](1)
println(list)
list = list ++ scala.collection.immutable.List[Int](2)
println(list)
// This operator does not exist on the List class, but has the same behavior as the operation above.
list ++= scala.collection.immutable.List[Int](3)
println(list)
}
Output
List(1)
List(1, 2)
List(1, 2, 3)
x ++= y appears to have the same behavior as x = x ++ y
It does.
but I cannot find where this behavior is coming form.
It's built into the language. When x op= y can't be interpreted as a calling the method op= (because no such method exists in x's class or any class that it can be implicitly converted to), it's instead interpreted as calling the method op and an assignment.
(and where is it documented?)
In Scala's language specification, section 6.12.4:
Assignment Operators
An assignment operator is an operator symbol (syntax category op in Identifiers) that ends in an equals character “=”, with the exception of operators for which one of the following conditions holds:
the operator also starts with an equals character, or
the operator is one of (<=), (>=), (!=).
Assignment operators are treated specially in that they can be expanded to assignments if no other interpretation is valid.
Let's consider an assignment operator such as += in an infix operation l += r, where l, r are expressions. This operation can be re-interpreted as an operation which corresponds to the assignment
l = l + r
except that the operation's left-hand-side l is evaluated only once.
The re-interpretation occurs if the following two conditions are fulfilled.
The left-hand-side l does not have a member named +=, and also cannot be converted by an implicit conversion to a value with a member named +=.
The assignment l = l + r is type-correct. In particular this implies that l refers to a variable or object that can be assigned to, and that is convertible to a value with a member named +.
As I read from book, scala operator associativity comes from left to right except operator ends with ":" char.
Given the val a = b = c, it becomes val a = (b = c) and makes a is initialized as Unit.
But why does not it become (val a = b) = c, and it cause that compile error because to use a Unit(returned from a=b) to receive c?
And after I really types (val a = b) = c, the compiler complains illeagal start of simple expression and pointers to val. Why are these two assignment operators not grouped from left to right?
The important thing to see here is that val a = b = c is a declaration and not an expression, but precedence and associativity are notions applying to expressions.
Looking at the Scala 2.11 Language Specification, 4.1 Value Declarations and Definitions, you can see that
val a = b = c
is a basic declaration falling into the PatVarDef case, so it can be read as (simplifying the Pattern2 part to the specific case of varid here):
'val' varid '=' Expr
Thus, here we have
the variable identifier varid is a,
the expression Expr is b = c,
a is assigned the value b = c evaluates to, which happens to be Unit.
For the later see What is the motivation for Scala assignment evaluating to Unit rather than the value assigned?
Note that the above assumes that b is a var, e.g.,
val c = 17
var b = 3
val a = b = c
as b is reassigned in the third line (else you would get error: reassignment to val). If you want to assign the same value to two val for some reason, you can use
val c = 17
val a, b = c