Types¶

Type Declarations¶

The :: operator can be used to attach type annotations to expressions and variables in programs. There are two primary reasons to do this:

1. As an assertion to help confirm that your program works the way you expect,
2. To provide extra type information to the compiler, which can then improve performance in some cases

When appended to an expression computing a value, the :: operator is read as “is an instance of”. It can be used anywhere to assert that the value of the expression on the left is an instance of the type on the right. When the type on the right is concrete, the value on the left must have that type as its implementation — recall that all concrete types are final, so no implementation is a subtype of any other. When the type is abstract, it suffices for the value to be implemented by a concrete type that is a subtype of the abstract type. If the type assertion is not true, an exception is thrown, otherwise, the left-hand value is returned:

julia>(1+2)::AbstractFloatERROR:TypeError:typeassert:expectedAbstractFloat,gotInt64...julia>(1+2)::Int3

This allows a type assertion to be attached to any expression in-place.

When appended to a variable on the left-hand side of an assignment, or as part of a local declaration, the :: operator means something a bit different: it declares the variable to always have the specified type, like a type declaration in a statically-typed language such as C. Every value assigned to the variable will be converted to the declared type using convert():

julia>function foo()x::Int8=100xendfoo(genericfunction with1method)julia>foo()100julia>typeof(ans)Int8

This feature is useful for avoiding performance “gotchas” that could occur if one of the assignments to a variable changed its type unexpectedly.

This “declaration” behavior only occurs in specific contexts:

localx::Int8# in a local declarationx::Int8=10# as the left-hand side of an assignment

and applies to the whole current scope, even before the declaration. Currently, type declarations cannot be used in global scope, e.g. in the REPL, since Julia does not yet have constant-type globals.

Declarations can also be attached to function definitions:

function sinc(x)::Float64ifx==0return1endreturnsin(pi*x)/(pi*x)end

Returning from this function behaves just like an assignment to a variable with a declared type: the value is always converted to Float64.

Abstract Types¶

Abstract types cannot be instantiated, and serve only as nodes in the type graph, thereby describing sets of related concrete types: those concrete types which are their descendants. We begin with abstract types even though they have no instantiation because they are the backbone of the type system: they form the conceptual hierarchy which makes Julia’s type system more than just a collection of object implementations.

Recall that in Integers and Floating-Point Numbers, we introduced a variety of concrete types of numeric values: Int8, UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64, Int128, UInt128, Float16, Float32, and Float64. Although they have different representation sizes, Int8, Int16, Int32, Int64 and Int128 all have in common that they are signed integer types. Likewise UInt8, UInt16, UInt32, UInt64 and UInt128 are all unsigned integer types, while Float16, Float32 and Float64 are distinct in being floating-point types rather than integers. It is common for a piece of code to make sense, for example, only if its arguments are some kind of integer, but not really depend on what particular kind of integer. For example, the greatest common denominator algorithm works for all kinds of integers, but will not work for floating-point numbers. Abstract types allow the construction of a hierarchy of types, providing a context into which concrete types can fit. This allows you, for example, to easily program to any type that is an integer, without restricting an algorithm to a specific type of integer.

Abstract types are declared using the abstract keyword. The general syntaxes for declaring an abstract type are:

abstract «name»
abstract «name» <: «supertype»

The abstract keyword introduces a new abstract type, whose name is given by «name». This name can be optionally followed by <: and an already-existing type, indicating that the newly declared abstract type is a subtype of this “parent” type.

When no supertype is given, the default supertype is Any — a predefined abstract type that all objects are instances of and all types are subtypes of. In type theory, Any is commonly called “top” because it is at the apex of the type graph. Julia also has a predefined abstract “bottom” type, at the nadir of the type graph, which is written as Union{}. It is the exact opposite of Any: no object is an instance of Union{} and all types are supertypes of Union{}.

Let’s consider some of the abstract types that make up Julia’s numerical hierarchy:

abstract Numberabstract Real<:Numberabstract AbstractFloat<:Realabstract Integer<:Realabstract Signed<:Integerabstract Unsigned<:Integer

The Number type is a direct child type of Any, and Real is its child. In turn, Real has two children (it has more, but only two are shown here; we’ll get to the others later): Integer and AbstractFloat, separating the world into representations of integers and representations of real numbers. Representations of real numbers include, of course, floating-point types, but also include other types, such as rationals. Hence, AbstractFloat is a proper subtype of Real, including only floating-point representations of real numbers. Integers are further subdivided into Signed and Unsigned varieties.

The <: operator in general means “is a subtype of”, and, used in declarations like this, declares the right-hand type to be an immediate supertype of the newly declared type. It can also be used in expressions as a subtype operator which returns true when its left operand is a subtype of its right operand:

julia>Integer<:Numbertruejulia>Integer<:AbstractFloatfalse

An important use of abstract types is to provide default implementations for concrete types. To give a simple example, consider:

function myplus(x,y)x+yend

The first thing to note is that the above argument declarations are equivalent to x::Any and y::Any. When this function is invoked, say as myplus(2,5), the dispatcher chooses the most specific method named myplus that matches the given arguments. (See Methods for more information on multiple dispatch.)

Assuming no method more specific than the above is found, Julia next internally defines and compiles a method called myplus specifically for two Int arguments based on the generic function given above, i.e., it implicitly defines and compiles:

function myplus(x::Int,y::Int)x+yend

and finally, it invokes this specific method.

Thus, abstract types allow programmers to write generic functions that can later be used as the default method by many combinations of concrete types. Thanks to multiple dispatch, the programmer has full control over whether the default or more specific method is used.

An important point to note is that there is no loss in performance if the programmer relies on a function whose arguments are abstract types, because it is recompiled for each tuple of argument concrete types with which it is invoked. (There may be a performance issue, however, in the case of function arguments that are containers of abstract types; see Performance Tips.)

Bits Types¶

A bits type is a concrete type whose data consists of plain old bits. Classic examples of bits types are integers and floating-point values. Unlike most languages, Julia lets you declare your own bits types, rather than providing only a fixed set of built-in bits types. In fact, the standard bits types are all defined in the language itself:

bitstype16Float16<:AbstractFloatbitstype32Float32<:AbstractFloatbitstype64Float64<:AbstractFloatbitstype8Bool<:Integerbitstype32Charbitstype8Int8<:Signedbitstype8UInt8<:Unsignedbitstype16Int16<:Signedbitstype16UInt16<:Unsignedbitstype32Int32<:Signedbitstype32UInt32<:Unsignedbitstype64Int64<:Signedbitstype64UInt64<:Unsignedbitstype128Int128<:Signedbitstype128UInt128<:Unsigned

The general syntaxes for declaration of a bitstype are:

bitstype«bits»«name»bitstype«bits»«name»<:«supertype»

The number of bits indicates how much storage the type requires and the name gives the new type a name. A bits type can optionally be declared to be a subtype of some supertype. If a supertype is omitted, then the type defaults to having Any as its immediate supertype. The declaration of Bool above therefore means that a boolean value takes eight bits to store, and has Integer as its immediate supertype. Currently, only sizes that are multiples of 8 bits are supported. Therefore, boolean values, although they really need just a single bit, cannot be declared to be any smaller than eight bits.

The types Bool, Int8 and UInt8 all have identical representations: they are eight-bit chunks of memory. Since Julia’s type system is nominative, however, they are not interchangeable despite having identical structure. Another fundamental difference between them is that they have different supertypes: Bool‘s direct supertype is Integer, Int8‘s is Signed, and UInt8‘s is Unsigned. All other differences between Bool, Int8, and UInt8 are matters of behavior — the way functions are defined to act when given objects of these types as arguments. This is why a nominative type system is necessary: if structure determined type, which in turn dictates behavior, then it would be impossible to make Bool behave any differently than Int8 or UInt8.

Composite Types¶

Composite types are called records, structures (structs in C), or objects in various languages. A composite type is a collection of named fields, an instance of which can be treated as a single value. In many languages, composite types are the only kind of user-definable type, and they are by far the most commonly used user-defined type in Julia as well.

In mainstream object oriented languages, such as C++, Java, Python and Ruby, composite types also have named functions associated with them, and the combination is called an “object”. In purer object-oriented languages, such as Ruby or Smalltalk, all values are objects whether they are composites or not. In less pure object oriented languages, including C++ and Java, some values, such as integers and floating-point values, are not objects, while instances of user-defined composite types are true objects with associated methods. In Julia, all values are objects, but functions are not bundled with the objects they operate on. This is necessary since Julia chooses which method of a function to use by multiple dispatch, meaning that the types of all of a function’s arguments are considered when selecting a method, rather than just the first one (see Methods for more information on methods and dispatch). Thus, it would be inappropriate for functions to “belong” to only their first argument. Organizing methods into function objects rather than having named bags of methods “inside” each object ends up being a highly beneficial aspect of the language design.

Since composite types are the most common form of user-defined concrete type, they are simply introduced with the type keyword followed by a block of field names, optionally annotated with types using the :: operator:

julia>type Foobarbaz::Intqux::Float64end

Fields with no type annotation default to Any, and can accordingly hold any type of value.

New objects of composite type Foo are created by applying the Foo type object like a function to values for its fields:

julia>foo=Foo("Hello, world.",23,1.5)Foo("Hello, world.",23,1.5)julia>typeof(foo)Foo

When a type is applied like a function it is called a constructor. Two constructors are generated automatically (these are called default constructors). One accepts any arguments and calls convert() to convert them to the types of the fields, and the other accepts arguments that match the field types exactly. The reason both of these are generated is that this makes it easier to add new definitions without inadvertently replacing a default constructor.

Since the bar field is unconstrained in type, any value will do. However, the value for baz must be convertible to Int:

julia>Foo((),23.5,1)ERROR:InexactError()inFoo(::Tuple{},::Float64,::Int64)at./none:2...

You may find a list of field names using the fieldnames function.

julia>fieldnames(foo)3-elementArray{Symbol,1}::bar:baz:qux

You can access the field values of a composite object using the traditional foo.bar notation:

julia>foo.bar"Hello, world."julia>foo.baz23julia>foo.qux1.5

You can also change the values as one would expect:

julia>foo.qux=22julia>foo.bar=1//21//2

Composite types with no fields are singletons; there can be only one instance of such types:

type NoFieldsendjulia>is(NoFields(),NoFields())true

The is function confirms that the “two” constructed instances of NoFields are actually one and the same. Singleton types are described in further detail below.

There is much more to say about how instances of composite types are created, but that discussion depends on both Parametric Types and on Methods, and is sufficiently important to be addressed in its own section: Constructors.

Immutable Composite Types¶

It is also possible to define immutable composite types by using the keyword immutable instead of type:

immutableComplexreal::Float64imag::Float64end

Such types behave much like other composite types, except that instances of them cannot be modified. Immutable types have several advantages:

• They are more efficient in some cases. Types like the Complex example above can be packed efficiently into arrays, and in some cases the compiler is able to avoid allocating immutable objects entirely.
• It is not possible to violate the invariants provided by the type’s constructors.
• Code using immutable objects can be easier to reason about.

An immutable object might contain mutable objects, such as arrays, as fields. Those contained objects will remain mutable; only the fields of the immutable object itself cannot be changed to point to different objects.

A useful way to think about immutable composites is that each instance is associated with specific field values — the field values alone tell you everything about the object. In contrast, a mutable object is like a little container that might hold different values over time, and so is not identified with specific field values. In deciding whether to make a type immutable, ask whether two instances with the same field values would be considered identical, or if they might need to change independently over time. If they would be considered identical, the type should probably be immutable.

To recap, two essential properties define immutability in Julia:

• An object with an immutable type is passed around (both in assignment statements and in function calls) by copying, whereas a mutable type is passed around by reference.
• It is not permitted to modify the fields of a composite immutable type.

It is instructive, particularly for readers whose background is C/C++, to consider why these two properties go hand in hand. If they were separated, i.e., if the fields of objects passed around by copying could be modified, then it would become more difficult to reason about certain instances of generic code. For example, suppose x is a function argument of an abstract type, and suppose that the function changes a field: x.isprocessed=true. Depending on whether x is passed by copying or by reference, this statement may or may not alter the actual argument in the calling routine. Julia sidesteps the possibility of creating functions with unknown effects in this scenario by forbidding modification of fields of objects passed around by copying.

Declared Types¶

The three kinds of types discussed in the previous three sections are actually all closely related. They share the same key properties:

• They are explicitly declared.
• They have names.
• They have explicitly declared supertypes.
• They may have parameters.

Because of these shared properties, these types are internally represented as instances of the same concept, DataType, which is the type of any of these types:

julia>typeof(Real)DataTypejulia>typeof(Int)DataType

A DataType may be abstract or concrete. If it is concrete, it has a specified size, storage layout, and (optionally) field names. Thus a bits type is a DataType with nonzero size, but no field names. A composite type is a DataType that has field names or is empty (zero size).

Every concrete value in the system is an instance of some DataType.

Type Unions¶

A type union is a special abstract type which includes as objects all instances of any of its argument types, constructed using the special Union function:

julia>IntOrString=Union{Int,AbstractString}Union{AbstractString,Int64}julia>1::IntOrString1julia>"Hello!"::IntOrString"Hello!"julia>1.0::IntOrStringERROR:type:typeassert:expectedUnion{AbstractString,Int64},gotFloat64

The compilers for many languages have an internal union construct for reasoning about types; Julia simply exposes it to the programmer.

Parametric Types¶

An important and powerful feature of Julia’s type system is that it is parametric: types can take parameters, so that type declarations actually introduce a whole family of new types — one for each possible combination of parameter values. There are many languages that support some version of generic programming, wherein data structures and algorithms to manipulate them may be specified without specifying the exact types involved. For example, some form of generic programming exists in ML, Haskell, Ada, Eiffel, C++, Java, C#, F#, and Scala, just to name a few. Some of these languages support true parametric polymorphism (e.g. ML, Haskell, Scala), while others support ad-hoc, template-based styles of generic programming (e.g. C++, Java). With so many different varieties of generic programming and parametric types in various languages, we won’t even attempt to compare Julia’s parametric types to other languages, but will instead focus on explaining Julia’s system in its own right. We will note, however, that because Julia is a dynamically typed language and doesn’t need to make all type decisions at compile time, many traditional difficulties encountered in static parametric type systems can be relatively easily handled.

All declared types (the DataType variety) can be parameterized, with the same syntax in each case. We will discuss them in the following order: first, parametric composite types, then parametric abstract types, and finally parametric bits types.

type Point{T}x::Ty::Tend

julia>Point{Float64}Point{Float64}julia>Point{AbstractString}Point{AbstractString}

julia>PointPoint{T}

julia>Point{Float64}<:Pointtruejulia>Point{AbstractString}<:Pointtrue

julia>Float64<:Pointfalsejulia>AbstractString<:Pointfalse

julia>Point{Float64}<:Point{Int64}falsejulia>Point{Float64}<:Point{Real}false

function norm(p::Point{Real})sqrt(p.x^2+p.y^2)end

function norm{T<:Real}(p::Point{T})sqrt(p.x^2+p.y^2)end

julia>Point{Float64}(1.0,2.0)Point{Float64}(1.0,2.0)julia>typeof(ans)Point{Float64}

julia>Point{Float64}(1.0)ERROR:MethodError:Cannot`convert`anobjectoftype Float64toanobjectoftype Point{Float64}ThismayhavearisenfromacalltotheconstructorPoint{Float64}(...),sincetype constructorsfallbacktoconvertmethods.inPoint{Float64}(::Float64)at./sysimg.jl:53...julia>Point{Float64}(1.0,2.0,3.0)ERROR:MethodError:nomethodmatchingPoint{Float64}(::Float64,::Float64,::Float64)Closestcandidatesare:Point{Float64}{T}(::Any,::Any)atnone:3Point{Float64}{T}(::Any)atsysimg.jl:53...

julia>Point(1.0,2.0)Point{Float64}(1.0,2.0)julia>typeof(ans)Point{Float64}julia>Point(1,2)Point{Int64}(1,2)julia>typeof(ans)Point{Int64}

julia>Point(1,2.5)ERROR:MethodError:nomethodmatchingPoint{T}(::Int64,::Float64)...

abstract Pointy{T}

julia>Pointy{Int64}<:Pointytruejulia>Pointy{1}<:Pointytrue

julia>Pointy{Float64}<:Pointy{Real}falsejulia>Pointy{Real}<:Pointy{Float64}false

type Point{T}<:Pointy{T}x::Ty::Tend

julia>Point{Float64}<:Pointy{Float64}truejulia>Point{Real}<:Pointy{Real}truejulia>Point{AbstractString}<:Pointy{AbstractString}true

julia>Point{Float64}<:Pointy{Real}false

type DiagPoint{T}<:Pointy{T}x::Tend

abstract Pointy{T<:Real}

julia>Pointy{Float64}Pointy{Float64}julia>Pointy{Real}Pointy{Real}julia>Pointy{AbstractString}ERROR:TypeError:Pointy:inT,expectedT<:Real,gotType{AbstractString}...julia>Pointy{1}ERROR:TypeError:Pointy:inT,expectedT<:Real,gotInt64...

type Point{T<:Real}<:Pointy{T}x::Ty::Tend

immutableRational{T<:Integer}<:Realnum::Tden::Tend

immutableTuple2{A,B}a::Ab::Bend

julia>typeof((1,"foo",2.5))Tuple{Int64,String,Float64}

julia>Tuple{Int,AbstractString}<:Tuple{Real,Any}truejulia>Tuple{Int,AbstractString}<:Tuple{Real,Real}falsejulia>Tuple{Int,AbstractString}<:Tuple{Real,}false

julia>isa(("1",),Tuple{AbstractString,Vararg{Int}})truejulia>isa(("1",1),Tuple{AbstractString,Vararg{Int}})truejulia>isa(("1",1,2),Tuple{AbstractString,Vararg{Int}})truejulia>isa(("1",1,2,3.0),Tuple{AbstractString,Vararg{Int}})false

julia>isa(Float64,Type{Float64})truejulia>isa(Real,Type{Float64})falsejulia>isa(Real,Type{Real})truejulia>isa(Float64,Type{Real})false

julia>isa(Type{Float64},Type)truejulia>isa(Float64,Type)truejulia>isa(Real,Type)true

julia>isa(1,Type)falsejulia>isa("foo",Type)false

# 32-bit system:bitstype32Ptr{T}# 64-bit system:bitstype64Ptr{T}

julia>Ptr{Float64}<:Ptrtruejulia>Ptr{Int64}<:Ptrtrue

Type Aliases¶

Sometimes it is convenient to introduce a new name for an already expressible type. For such occasions, Julia provides the typealias mechanism. For example, UInt is type aliased to either UInt32 or UInt64 as is appropriate for the size of pointers on the system:

# 32-bit system:julia>UIntUInt32# 64-bit system:julia>UIntUInt64

This is accomplished via the following code in base/boot.jl:

ifis(Int,Int64)typealias UIntUInt64elsetypealias UIntUInt32end

Of course, this depends on what Int is aliased to — but that is predefined to be the correct type — either Int32 or Int64.

For parametric types, typealias can be convenient for providing names for cases where some of the parameter choices are fixed. Julia’s arrays have type Array{T,N} where T is the element type and N is the number of array dimensions. For convenience, writing Array{Float64} allows one to specify the element type without specifying the dimension:

julia>Array{Float64,1}<:Array{Float64}<:Arraytrue

However, there is no way to equally simply restrict just the dimension but not the element type. Yet, one often needs to ensure an object is a vector or a matrix (imposing restrictions on the number of dimensions). For that reason, the following type aliases are provided:

typealias Vector{T}Array{T,1}typealias Matrix{T}Array{T,2}

Writing Vector{Float64} is equivalent to writing Array{Float64,1}, and the umbrella type Vector has as instances all Array objects where the second parameter — the number of array dimensions — is 1, regardless of what the element type is. In languages where parametric types must always be specified in full, this is not especially helpful, but in Julia, this allows one to write just Matrix for the abstract type including all two-dimensional dense arrays of any element type.

This declaration of Vector creates a subtype relation Vector{Int}<:Vector. However, it is not always the case that a parametric typealias statement creates such a relation; for example, the statement:

typealias AA{T}Array{Array{T,1},1}

does not create the relation AA{Int}<:AA. The reason is that Array{Array{T,1},1} is not an abstract type at all; in fact, it is a concrete type describing a 1-dimensional array in which each entry is an object of type Array{T,1} for some value of T.

Operations on Types¶

Since types in Julia are themselves objects, ordinary functions can operate on them. Some functions that are particularly useful for working with or exploring types have already been introduced, such as the <: operator, which indicates whether its left hand operand is a subtype of its right hand operand.

The isa function tests if an object is of a given type and returns true or false:

julia>isa(1,Int)truejulia>isa(1,AbstractFloat)false

The typeof() function, already used throughout the manual in examples, returns the type of its argument. Since, as noted above, types are objects, they also have types, and we can ask what their types are:

julia>typeof(Rational)DataTypejulia>typeof(Union{Real,Float64,Rational})DataTypejulia>typeof(Union{Real,String})Union

What if we repeat the process? What is the type of a type of a type? As it happens, types are all composite values and thus all have a type of DataType:

julia>typeof(DataType)DataTypejulia>typeof(Union)DataType

DataType is its own type.

Another operation that applies to some types is supertype(), which reveals a type’s supertype. Only declared types (DataType) have unambiguous supertypes:

julia>supertype(Float64)AbstractFloatjulia>supertype(Number)Anyjulia>supertype(AbstractString)Anyjulia>supertype(Any)Any

If you apply supertype() to other type objects (or non-type objects), a MethodError is raised:

julia>supertype(Union{Float64,Int64})ERROR:`supertype`hasnomethodmatchingsupertype(::Type{Union{Float64,Int64}})

“Value types”¶

In Julia, you can’t dispatch on a value such as true or false. However, you can dispatch on parametric types, and Julia allows you to include “plain bits” values (Types, Symbols, Integers, floating-point numbers, tuples, etc.) as type parameters. A common example is the dimensionality parameter in Array{T,N}, where T is a type (e.g., Float64) but N is just an Int.

You can create your own custom types that take values as parameters, and use them to control dispatch of custom types. By way of illustration of this idea, let’s introduce a parametric type, Val{T}, which serves as a customary way to exploit this technique for cases where you don’t need a more elaborate hierarchy.

Val is defined as:

immutableVal{T}end

There is no more to the implementation of Val than this. Some functions in Julia’s standard library accept Val types as arguments, and you can also use it to write your own functions. For example:

firstlast(::Type{Val{true}})="First"firstlast(::Type{Val{false}})="Last"julia>firstlast(Val{true})"First"julia>firstlast(Val{false})"Last"

For consistency across Julia, the call site should always pass a Valtype rather than creating an instance, i.e., use foo(Val{:bar}) rather than foo(Val{:bar}()).

It’s worth noting that it’s extremely easy to mis-use parametric “value” types, including Val; in unfavorable cases, you can easily end up making the performance of your code much worse. In particular, you would never want to write actual code as illustrated above. For more information about the proper (and improper) uses of Val, please read the more extensive discussion in the performance tips.

Nullable Types: Representing Missing Values¶

In many settings, you need to interact with a value of type T that may or may not exist. To handle these settings, Julia provides a parametric type called Nullable{T}, which can be thought of as a specialized container type that can contain either zero or one values. Nullable{T} provides a minimal interface designed to ensure that interactions with missing values are safe. At present, the interface consists of four possible interactions:

• Construct a Nullable object.
• Check if a Nullable object has a missing value.
• Access the value of a Nullable object with a guarantee that a NullException will be thrown if the object’s value is missing.
• Access the value of a Nullable object with a guarantee that a default value of type T will be returned if the object’s value is missing.

julia>x1=Nullable{Int64}()Nullable{Int64}()julia>x2=Nullable{Float64}()Nullable{Float64}()julia>x3=Nullable{Vector{Int64}}()Nullable{Array{Int64,1}}()

julia>x1=Nullable(1)Nullable{Int64}(1)julia>x2=Nullable(1.0)Nullable{Float64}(1.0)julia>x3=Nullable([1,2,3])Nullable{Array{Int64,1}}([1,2,3])

julia>isnull(Nullable{Float64}())truejulia>isnull(Nullable(0.0))false

julia>get(Nullable{Float64}())ERROR:NullException()inget(::Nullable{Float64})at./nullable.jl:62...julia>get(Nullable(1.0))1.0

julia>get(Nullable{Float64}(),0.0)0.0julia>get(Nullable(1.0),0.0)1.0