Operator Overloading in Scala

You've been writing dynamic, duck-typed Python for years, and you can add two vectors with + in a class by defining __add__. Now you're learning Scala, where every operator is a method, and operator overloading isn't a special hook but a natural consequence of the language's design. In Python, operator overloading is a special protocol; in Scala, it's just method invocation with syntactic sugar. By the end of this lesson, you'll not only define custom operators but also read and write idiomatic Scala that feels as expressive as Python — with the safety net of a powerful static type system.

The problem this lesson solves

Python developers often struggle when they first see Scala code like a + b and wonder: How does the + method know how to work on my custom class? In Python, you might have __add__, __radd__, __iadd__ — a whole dunder protocol. In Scala, the answer is simpler: + is a method on the left operand. But this simplicity can be deceptive. If you come from Python, you might expect to use dunder names or worry about method resolution order. This lesson unravels that mystery, showing you exactly how Scala's uniform access principle and method invocation model work together.

Another pain point: Python's operator overloading is strict — you only get the predefined operators. Scala lets you define any symbolic method, so you can create new operators like --> or <=> if you want. This power can be abused, leading to cryptic code. This lesson shows you the idiomatic way to use operator overloading in Scala, balancing expressiveness with readability.

Core concept / mental model

Think of Python as a language with a special protocol for operators. To make + work on your class, you must implement __add__ in a specific way. Scala has a uniform method invocation model: everything is a method call, and operators are just method names with symbolic characters.

Here's a mental model: In Scala, a + b is semantically identical to a.+(b). The compiler reads + as a method name and invokes it on the left operand. There is no separate operator table. When you write a.+(b), you're explicitly calling a method named +. When you write a + b, you're using syntactic sugar that the compiler converts to the same method call.

This model is reminiscent of Python's __add__, but without the underscore protocol. In Scala, if you define a method with a symbolic name, it's automatically an operator. You don't need to register it or follow a naming convention beyond the allowed character set.

Key insight: In Scala, any method can be called in infix notation if it takes one parameter. This is not limited to operators. For example, myList.foreach(print) can be written myList foreach print. This is called infix notation, and it's a powerful feature that makes DSLs (Domain-Specific Languages) possible.

How it works step by step

Let's break down the process of defining and using custom operators in Scala.

1. Recognize that operators are methods: In Scala, +, -, *, /, ==, <, and even +++ are all valid method names. They can be defined like any other method.

2. Define a method with an operator name: Inside a class, you define a method like def +(other: MyType): MyReturnType = .... The method name comes after def, just like a normal method.

3. Call the method in infix notation: To use it as an operator, you write a + b. The compiler translates this to a.+(b). If your method takes more than one parameter, you must use dot notation a.+(b, c) or use braces a + (b, c) — the latter is less common.

4. Understand precedence: Scala has a fixed precedence based on the first character of the operator. For example, * has higher precedence than +, and + has higher precedence than ==. This table is not flexible, so you can't change operator precedence.

5. Handle symmetry with implicit conversions or AnyVal: In Python, you can define __radd__ to handle 5 + vector. In Scala, you use implicit conversions or value classes to enable similar behavior. This is more explicit but also more powerful.

Let's see this in code.

Hands-on walkthrough

Let's write a Vector2D class that supports vector addition, subtraction, and scalar multiplication. You'll see how Scala's operator overloading works in practice.

Step 1: Define a class with a + method

// Vector2D.scala
class Vector2D(val x: Double, val y: Double) {
  def +(other: Vector2D): Vector2D =
    new Vector2D(x + other.x, y + other.y)

  def -(other: Vector2D): Vector2D =
    new Vector2D(x - other.x, y - other.y)

  def *(scalar: Double): Vector2D =
    new Vector2D(x * scalar, y * scalar)

  override def toString: String = s"($x, $y)"
}

object Vector2DApp extends App {
  val a = new Vector2D(1, 2)
  val b = new Vector2D(3, 4)
  val sum = a + b
  val diff = a - b
  val scaled = a * 2.0
  println(sum)   // (4.0, 6.0)
  println(diff)  // (-2.0, -2.0)
  println(scaled) // (2.0, 4.0)
}

When you run scala Vector2DApp.scala, you'll see:

(4.0, 6.0)
(-2.0, -2.0)
(2.0, 4.0)

Note how a + b is exactly a.+(b). You can even call a.+(b) explicitly for clarity when needed.

Step 2: Compare with Python

Here's the equivalent Python class for comparison:

class Vector2D:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __add__(self, other):
        return Vector2D(self.x + other.x, self.y + other.y)

    def __sub__(self, other):
        return Vector2D(self.x - other.x, self.y - other.y)

    def __mul__(self, scalar):
        return Vector2D(self.x * scalar, self.y * scalar)

    def __str__(self):
        return f"({self.x}, {self.y})"

a = Vector2D(1, 2)
b = Vector2D(3, 4)
print(a + b)  # (4, 6)

The key difference: Python uses __add__ as a special dunder method; Scala uses def +(...). In Scala, + is just a method name, not a special protocol.

Step 3: Define a custom operator (e.g., dot or -->)

You can define any symbolic method. Here's a dot method for dot product, but using a symbolic name like ** for exponentiation or |*| for a cross product.

class Vector2D(val x: Double, val y: Double) {
  // ... previous methods ...

  def **(other: Vector2D): Double =
    x * other.x + y * other.y  // dot product

  def |*|(other: Vector2D): Double =
    x * other.y - y * other.x  // cross product magnitude
}

// Usage:
val dot = a ** b  // a.**(b)
val cross = a |*| b // a.|*|(b)

Practical note: While Scala allows any symbolic name, idiomatic Scala uses symbolic operators only when they're well understood in the domain (e.g., +, -, *, /). For domain-specific operations, prefer descriptive method names like dot or cross, or use backticks to define alphanumeric methods with backticks: dot. But that's not common.

Step 4: Handle scalar multiplication on the left

Python handles 2 * vector with __rmul__. In Scala, you can use implicit conversions or case classes with a companion object to achieve similar behavior.

object Vector2D {
  implicit def fromDouble(x: Double): Vector2D = new Vector2D(x, 0)
}

// Now you can do:
val scaled = 2.0 * a

Because 2.0 is a Double, and there's an implicit conversion to Vector2D, the compiler will treat 2.0 * a as (2.0).*(a). Since Double doesn't have a *(Vector2D) method, it looks for an implicit conversion and finds one. It converts 2.0 to Vector2D(2, 0) and then calls .*.

But — this can be dangerous because Double already has many * methods for numeric types. The implicit conversion may cause unexpected hiding or ambiguous overloads. A safer approach is to define unary_* in companion objects, or better, use implicit classes to add methods to Double:

implicit class RichDouble(val d: Double) extends AnyVal {
  def *(v: Vector2D): Vector2D = new Vector2D(d * v.x, d * v.y)
}

val scaled = 2.0 * a  // works

This is cleaner and avoids polluting Double's methods.

Compare options / when to choose what

Key principle: In Scala, it's idiomatic to use operators for algebraic structures (numeric types, collections) and symbolic DSLs, but you must always consider readability. If an operator isn't self-explanatory, prefer a named method.

Troubleshooting & edge cases

Common error: Type mismatch with operator precedence

You might write a + b * 2 and get a type error. Remember that * binds tighter than + based on precedence. Use parentheses when in doubt.

Error: Operator not a member of the type

If you try a + b where a is of type String and b is Int, Scala will complain because String doesn't have +(Int). Unlike Python, it won't coerce implicitly.

Error: Ambiguous implicit conversions

When you have multiple implicit conversions for the same pair of types, the compiler throws an ambiguity error. Keep implicit conversions minimal.

Edge case: == versus equals

In Scala, == is final and calls equals. If you override equals, you ensure == works. But you can't override == itself. Override equals in your class to define value equality — just like Python's __eq__.

Edge case: Unary operators

To define a unary - for Vector2D, use def unary_- = new Vector2D(-x, -y). This is different from binary -. This is a special name that the compiler recognizes.

What you learned & what's next

You now understand that operator overloading in Scala is simply method invocation with symbolic method names. You've seen how to define +, -, *, and even custom operators, and how to handle scalar multiplication with implicits. You've also learned about operator precedence and the importance of keeping code readable.

These skills are foundational for writing expressive, DSL-like Scala code. Next in this track, you'll dive into pattern matching and case classes, where you'll see how Scala's syntax for matching and destructuring builds on this same uniform method model. You'll apply your knowledge of method invocation to create powerful, type-safe code.

Take a moment to reflect: How would you design a mathematical library in Scala using operators? How does this compare to Python? Now try implementing a simple Complex number class with +, -, *, and / as an exercise. Check that your code stays readable.