Custom Types and Structs

A struct in Julia declares a new composite type with named, typed fields — for example, struct Point x::Float64; y::Float64 end defines a Point type with two Float64 fields. By default, structs are immutable: once a Point is constructed, its x and y fields cannot be reassigned, which lets the compiler store instances more efficiently (often directly on the stack or inline inside containers) and reason more confidently about the code. Julia automatically generates a default positional constructor, so Point(1.0, 2.0) works immediately without writing any constructor code yourself.

Prefixing the declaration with mutable struct allows fields to be reassigned after construction, at the cost of the extra indirection and allocation that heap-allocated, mutable objects require. Custom inner constructors — defined inside the struct body using the special new() function — let you validate or transform arguments before constructing the instance, for example rejecting a negative radius in a Circle struct; outer constructors, defined outside the struct body as ordinary methods, add convenience forms like a default constructor that fills in a missing field, without touching the type's core definition.

Structs can be parameterized over types, as in struct Point{T} x::T; y::T end, letting a single definition serve Point{Int64}, Point{Float64}, or even Point{Rational{Int}} while keeping each field concretely typed for that instance. This matters for performance: a field declared as T (a type parameter bound to a concrete type at construction) lets the compiler generate specialized, unboxed machine code for each concrete instantiation, whereas a field declared with an abstract type like Real would force Julia to box every value and dispatch dynamically at each field access.

Once a struct exists, you define behavior for it by writing ordinary functions whose argument types include that struct, such as area(c::Circle) = π * c.radius^2 — Julia's multiple dispatch then selects the most specific matching method at each call site based on the runtime types of all arguments, not just the first one as in classical single-dispatch object-oriented languages. This means you can later define area(r::Rectangle) or even overlap(c::Circle, r::Rectangle) as separate methods of the same generic function name, and Julia will route each call to the correct implementation automatically.