7d. Preliminaries on Types

Introduction

High performance in Julia depends critically on the notion of type stability. The definition of this concept is relatively straightforward: a function is type-stable when the types of its expressions can be inferred from the types of its arguments. When this property holds, Julia can specialize its computation method, resulting in significant performance gains.

Despite its simplicity, type stability is subject to various nuances. In fact, a careful consideration of the property requires a solid foundation in two key areas: Julia's type system and the inner workings of functions. The current section equips you with the necessary knowledge to grasp the former, deferring the internals of functions to the next section. The explanations will focus on the case of scalars and vectors, leaving more complex objects for subsequent sections.

Before you continue, I recommend reviewing the basics of types introduced here.

Warning!

The subject is covered only to the extent necessary for understanding type stability. Julia's type system is indeed quite vast, and a comprehensive exploration would warrant a dedicated chapter.

Abstract and Concrete Types

The hierarchical nature of types makes it possible to represent subtypes and supertypes as trees. Such structure gives rise to the notions of abstract and concrete types.

An abstract type acts as a parent category, necessarily breaking down into subtypes. The type Any in Julia is a prime example. In contrast, a concrete type represents an irreducible unit that therefore lacks subtypes. Concrete types are considered final, in the sense that they can’t be further specialized within the hierarchy.

The diagram below illustrates the difference between abstract and concrete types for scalars. In particular, we present the hierarchy of the type Number, where the labels included match the corresponding type name in Julia. [note] The Signed subtype of Integers allows for the representation of negative and positive integers. Julia also offers the type Unsigned, which only accepts positive integers and comprises subtypes such as UInt64 and UInt32.

Hierarchy of Type Number

Note: Dashed red borders indicate abstract types, while solid blue borders indicate concrete types.

The distinction between abstract and concrete types for scalars is relatively straightforward. Instead, the same distinction becomes more nuanced when vectors are considered, as shown in the diagram below.

Hierarchy of Type Vector

Note: Dashed red borders indicate abstract types, while solid blue borders indicate concrete types.

The tree reveals that Vector{T} for a given type T is a concrete type. This means that variables can be instances of Vector{T}, where Vector{T} doesn't have subtypes. The consequence is that a vector like Vector{Int64} isn't a subtype of Vector{Any}, even though Int64 is a subtype of Any. This behavior stands in stark contrast to scalars, where Any is an abstract type. However, it aligns perfectly with the concept of vectors as collections of homogeneous elements, meaning that all elements share the same type.

Only concrete Types Can be Instantiated, Abstract Types Can't

In Julia, instantiation refers to the process of creating an object with a specific type. A key principle of Julia's type system is that only concrete types can be instantiated, implying that values can never be represented by abstract types. This distinction helps clarify the meaning of some widespread expressions used in Julia. For example, stating that a variable has type Any shouldn’t be interpreted literally. Rather, it means the variable can hold values of any concrete type, considering that all concrete types are subtypes of Any.

This distinction will become crucial for what follows, particularly for type-annotating variables. It implies that declaring a variable with an abstract type restricts the set of possible concrete types it can hold, even though the variable will ultimately adopt a concrete type.

Relevance for Type Stability

At this point, you may be wondering how all these concepts relate to type stability. The connection becomes clear when you consider how Julia performs computations.

High performance in Julia relies heavily on specializing the computation method. We'll see that this specialization is unattainable in the global scope, as Julia treats global variables as potentially holding values of any type. In contrast, when code is wrapped in a function, the execution process begins by determining the concrete types of each function argument. This information is then used to infer the concrete types of all the expressions within the function body.

When this inference succeeds and all expressions have unambiguous concrete types, the function is considered type stable. Type stability enables Julia to specialize its computation method and generate optimized machine code. If, instead, expressions could potentially take on multiple concrete types, performance is substantially degraded, as Julia must consider a separate implementation for each possible type.

For scalars and vectors, type stability essentially requires that expressions ultimately operate on primitive types. Examples of numeric primitive types include integers and floating-point numbers, such as Int64, Float64, and Bool. Thus, applying functions like sum to a Vector{Int64} or Vector{Float64} allows for full specialization, whereas applying them to a Vector{Any} prevents it.

String Objects

For text representation, the character type Char serves as a primitive type. Since a String is internally represented as a collection of Char elements, operations on String objects can also achieve type stability.

Type-Annotating Variables

In the following, we present methods for type-annotating variables. The techniques introduced can be used either to assert a variable's type during an assignment or to restrict the types of function arguments.

Specifically, there are two approaches to type-annotating variables. The first one relies on the binary operator ::, and its syntax is x::<type>. The second approach leverages the Boolean binary operator <:, combined with :: and the keyword where. Its syntax is x::T where T <: <type> (note that T accepts any other letter).

Next, we illustrate both methods, separately considering type-annotations for both assignments and function arguments.

Assignments

Let's start illustrating the approaches based on scalar assignments. Each tab below declares an identical type for x and for y.

x::Int64               = 2      # only reassignments to `Int64` are possible

y::Number              = 2      # only reassignments to `Float64`, `Float32`, `Int64`, etc are possible

x::T where T <: Int64  = 2      # only reassignments to `Int64` are possible

y::T where T <: Number = 2      # only reassignments to `Float64`, `Float32`, `Int64`, etc are possible

Warning! - Modifying Types

Once a type for x has been assigned, the type can't be changed. The only way to fix this is by starting a new session.

The fact that x holds the same type across all tabs follows because T <: Float64 can only represent Float64. More specifically, Float64 is a concrete type, which by definition has no subtypes other than itself. Considering this, scalar types are usually asserted using :: rather than <:.

While this behavior holds for scalars, it doesn't apply to vectors. Specifically, using :: in combination with Vector{Number} establishes that the object will have Vector{Number} as its concrete type. Instead, Vector{T} where T <: Number indicates that the elements of the vector will adopt a concrete subtype of Number.

# `x` will always be `Vector{Any}`
x::Vector{Any}                 = [1,2,3]

# `y` will always be `Vector{Number}`
y::Vector{Number}              = [1,2,3]

# `x` is Vector{Int64} and could eventually become `Vector{Float64}`, `Vector{String}`, etc
x::Vector{T} where T <:Any     = [1,2,3]

# `x` is Vector{Int64} and could eventually become `Vector{Float64}`, `Vector{Int32}`, etc
y::Vector{T} where T <: Number = [1,2,3]

The principles outlined apply even when a variable isn't explicitly type-annotated. The reason is that an assignment without :: implicitly assigns the type Any to the variable, where Any is the supertype encompassing all possible types. For example, the statements x = 2 and x::Any = 2 are equivalent.

The same occurs when omitting <: from the expression where T, which implicitly takes T <: Any. Thus, for instance, x = 2 is equivalent to x::T where T = 2 or x::T where T <: Any = 2. Considering this, all variables listed below have their types constrained in a similar manner.

# all are equivalent
a      = 2
b::Any = 2

# all are equivalent
a                   = 2
b::T where T        = 2
c::T where T <: Any = 2

Once we recognize that variables default to the type Any, it becomes clear why they can be reassigned with values of different types. For instance, given a = 1, executing a = "hello" afterwards is valid, since a is implicitly type-annotated with Any.

Warning! - One-liner Statements Using `where`

Be careful with one-liner statements using where, especially when where T is shorthand for where T <: Any. These concise statements can easily lead to confusion, as demonstrated below.

<: and Assignment <: and Function

a::T where T = 2                  # this is not `T = 2`, it's `a = 2`

a::T where {T}        = 2         # slightly less confusing notation
a::T where {T <: Any} = 2         # slightly less confusing notation

foo(x::T) where T = 2             # this is not `T = 2`, it's `foo(x) = 2`

foo(x::T) where {T}        = 2    # slightly less confusing notation
foo(x::T) where {T <: Any} = 2    # slightly less confusing notation

Functions

Function arguments can also be type-annotated. This is illustrated below, where functions are restricted to integer inputs exclusively.

function foo1(x::Int64, y::Int64)
    x + y 
end

function foo2(x::Vector{T}, y::Vector{T}) where T <: Int64
    x .+ y 
end

Note that when both function arguments are annotated with the same type parameter T, they're constrained to have exactly the same type. Also notice that types like Int64 preclude the use of Float64, even for numbers like 3.0. To allow greater flexibility, you should introduce separate type parameters and annotate them with a common abstract type like Number.

function foo2(x::T, y::T) where T <: Number
    x + y 
end

function foo3(x::T, y::S) where {T <: Number, S <: Number} 
    x + y 
end

The greatest flexibility is achieved when we don't type-annotate function arguments at all, as they will implicitly default to Any. This can be observed below, where all tabs define identical functions. Ultimately, type-annotating function arguments is only needed to prevent invalid usage (e.g., to ensure that log isn't applied to a negative value).

function foo(x, y)
    x + y 
end

function foo(x::Any, y::Any)
    x + y 
end

function foo(x::T, y::S) where {T <: Any, S <: Any} 
    x + y 
end

function foo(x::T, y::S) where {T, S} 
    x + y 
end