Is there any reason for Scala not support the ++ operator to increment primitive types by default? For example, you can not write:
var i=0 i++
Thanks
In Scala, ++ is a valid method, and no method implies assignment. Only = can do that. A longer answer is that languages like C++ and Java treat ++ specially, and Scala treats = specially, and in an inconsistent way.
There are no ++ or -- operators in Scala (use += or -=) Second, Scala encourages the use of immutable values, and with immutable values you'll have no need for these operators.
The difference between val and var is that val makes a variable immutable — like final in Java — and var makes a variable mutable.
An operator is a symbol that tells the compiler to perform specific mathematical or logical manipulations. Scala is rich in built-in operators and provides the following types of operators − Arithmetic Operators. Relational Operators.
My guess is this was omitted because it would only work for mutable variables, and it would not make sense for immutable values. Perhaps it was decided that the ++
operator doesn't scream assignment, so including it may lead to mistakes with regard to whether or not you are mutating the variable.
I feel that something like this is safe to do (on one line):
i++
but this would be a bad practice (in any language):
var x = i++
You don't want to mix assignment statements and side effects/mutation.
I like Craig's answer, but I think the point has to be more strongly made.
There are no "primitives" -- if Int
can do it, then so can a user-made Complex
(for example).
Basic usage of ++
would be like this:
var x = 1 // or Complex(1, 0)
x++
How do you implement ++
in class Complex
? Assuming that, like Int
, the object is immutable, then the ++
method needs to return a new object, but that new object has to be assigned.
It would require a new language feature. For instance, let's say we create an assign
keyword. The type signature would need to be changed as well, to indicate that ++
is not returning a Complex
, but assigning it to whatever field is holding the present object. In Scala spirit of not intruding in the programmers namespace, let's say we do that by prefixing the type with @
.
Then it could be like this:
case class Complex(real: Double = 0, imaginary: Double = 0) { def ++: @Complex = { assign copy(real = real + 1) // instead of return copy(real = real + 1) }
The next problem is that postfix operators suck with Scala rules. For instance:
def inc(x: Int) = { x++ x }
Because of Scala rules, that is the same thing as:
def inc(x: Int) = { x ++ x }
Which wasn't the intent. Now, Scala privileges a flowing style: obj method param method param method param ...
. That mixes well C++/Java traditional syntax of object method parameter
with functional programming concept of pipelining an input through multiple functions to get the end result. This style has been recently called "fluent interfaces" as well.
The problem is that, by privileging that style, it cripples postfix operators (and prefix ones, but Scala barely has them anyway). So, in the end, Scala would have to make big changes, and it would be able to measure up to the elegance of C/Java's increment and decrement operators anyway -- unless it really departed from the kind of thing it does support.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With