Overloading is illegal in Ceylon. A type may not have:

A type may be a subtype of another type. Subtyping obeys the following rules:

Every interface type is a subtype of the class Object defined in ceylon.language.

If X is a subtype of Y, then:

Furthermore, we say that X is assignable to Y.

For any types X and Y, the union, or disjunction, X|Y, of the types may be formed. A union type is a supertype of both of the given types X and Y, and an instance of either type is an instance of the union type.

The union type constructor | is associative, so the union of three types, X, Y, and Z, may be written X|Y|Z.

UnionType: IntersectionType ("|" IntersectionType)*

If X and Y are both subtypes of a third type Z, then X|Y inherits all members of Z.

void write(String|Integer|Float printable) { ... }

Union types satisfy the following rules, for any types X, Y, and Z:

The following results follow from these rules:

Finally:

For any types X and Y, the intersection, or conjunction, X&Y, of the types may be formed. An intersection type is a subtype of both of the given types X and Y, and any object which is an instance of both types is an instance of the intersection type.

The intersection type constructor & is associative, so the intersection of three types, X, Y, and Z, may be written X&Y&Z.

IntersectionType: PrimaryType ("&" PrimaryType)*

The intersection X&Y inherits all members of both X and Y.

void store(Persistent&Printable&Identifiable storable) { ... }

Intersection types satisfy the following rules, for any types X, Y, and Z:

The following results follow from these rules:

Finally:

The special type Nothing, sometimes called the bottom type, represents:

Nothing is assignable to all other types, but has no instances.

The type schema for Nothing is empty, that is, it is considered to have no members.

Nothing is considered to belong to the module ceylon.language. However, it cannot be defined within the language.

Because of the restrictions imposed by Ceylon's mixin inheritance model:

An expression, as defined in Chapter 6, Expressions, occurring at a certain location, may be assignable to a type. In this case, every evaluation of the expression at runtime produces an instance of a class that is a subtype of the type, or results in a thrown exception, as defined in Chapter 8, Execution.

Given an expression occurring at a certain location, a type T is the principal type of the expression if, given any type U to which the expression is assignable, T is a subtype of U. Thus, the principal type is the "most precise" type for the expression. The type system guarantees that every expression has a principal type. Thus, we refer uniquely to the type of an expression, meaning its principal type at the location at which it occurs.

Function and value declarations usually declare a type, by specifying a type expression.

Type: UnionType | EntryType

Type expressions are formed by combining types using union, intersection, and type abbreviations.

Type expressions support grouping using angle brackets:

GroupedType: "<" Type ">"

Applied types are identified by the name of the type (a class, interface, type alias, or type parameter), together with a list of type arguments if the type declaration is generic.

TypeNameWithArguments: TypeName TypeArguments?

Type names are resolved to type declarations according to §5.1.7 Unqualified reference resolution and §5.1.8 Qualified reference resolution.

The type argument list, if any, must conform, as defined by §3.6.1 Type arguments and type constraints, to the type parameter list of the realization of the type declaration, as defined by §3.7.6 Realizations.

If the type is a class, interface, or type alias nested inside a containing class or interface, the type must be fully qualified by its containing types, except when used inside the body of a containing type.

QualifiedType: TypeNameWithArguments ("." TypeNameWithArguments)*

If a type declaration is generic, a type argument list must be specified. If a type declaration is not generic, no type argument list may be specified.

BufferedReader.Buffer

Entry<Integer,Element>

Certain important types may be written using an abbreviated syntax.

PrimaryType: AtomicType | OptionalType | SequenceType | CallableType

AtomicType: QualifiedType | EmptyType | TupleType | IterableType | GroupedType

First, there are postfix-style abbreviations for optional types, sequence types, and callable types.

OptionalType: PrimaryType "?"

SequenceType: PrimaryType "[" "]"

CallableType: PrimaryType "(" TypeList? ")"

More precisely, the type meant by a callable type abbreviation is Callable<X,T> where X is the type outside the parentheses in the the callable type abbreviation, and T is the tuple type formed by the types listed inside the parentheses.

Next, abbreviations for iterable types are written using braces.

IterableType: "{" UnionType ("*"|"+") "}"

Next, abbreviations for sequence types and tuple types may be written using brackets.

EmptyType: "[" "]"

TupleType: "[" TypeList "]"

TypeList: (EntryType ",")* UnionType ("*"|"+")?

More precisely:

Finally, an entry type may be abbreviated using an arrow.

EntryType: UnionType "->" UnionType

Abbreviations may be combined:

String?[] words = { "hello", "world", null };
String? firstWord = words[0];

String->[Integer,Integer] onetwo = "onetwo"->[1, 2];

[Float+](Float x, Float[] xs) add = (Float x, Float[] xs) => [x, *xs];

When a type appears in a value expression, these abbreviations cannot be used (they cannot be disambiguated from operator expressions).

Certain declarations which usually require an explicit type may omit the type, forcing the compiler to infer it, by specifying the keyword value, as defined in §4.8.4 Value type inference, or function, as defined in §4.7.4 Function return type inference, where the type usually appears.

value names = people*.name;

function parse(String text) => text.split(" .!?,:;()\n\f\r\t".contains);

Type inference is only allowed for declarations which are referred to only by statements and declarations that occur within the lexical scope of the declaration, as specified by §5.1.6 Type inference and block structure. A value or function declaration may not:

Nor may a parameter or forward-declared value, as defined in §4.8.5 Forward declaration of values, or of a forward-declared function, as defined in §4.7.5 Forward declaration of functions, have an inferred type.

These restrictions allow the compiler to infer undeclared types in a single pass of the code.

value one;
if (float) {
    one = 1.0;
    Float float = one;
}
else {
    one = 1;
    Integer int = one;
}
Float|Integer num = one;

An inferred type never involves an anonymous class, as defined in §4.5.7 Anonymous classes. When an inferred type would involve an anonymous class type, the anonymous class is replaced by the intersection of the class type it extends with all interface types it satisfies.

A type alias is a synonym for another type. A generic type alias is a type constructor that produces a type alias, given a list of type arguments.

Every type alias must be reducible to an equivalent type that does not involve any type aliases by recursive replacement of type aliases with the types they alias. Thus, circular type alias definitions, as in the following example, are illegal:

alias X => List<Y>;
alias Y => List<X>;

Replacement of type aliases with the types they alias occurs at compile time, so type aliases are not reified types, as specified in §8.1.2 Type argument reification.

Inheritance relationships between classes, interfaces, and type parameters result in subtyping relationships between types.

A class may extend another class, in which case the first class is a subtype of the second class and inherits its members.

ExtendedType: "extends" ("super" ".")? TypeNameWithArguments PositionalArguments

The extends clause must specify exactly one superclass.

The type arguments may not be inferred from the initializer arguments.

extends Person(name, org)

A member class annotated actual may use the qualifier super in the extends clause to refer to the member class it refines. When the qualifier super appears, the following class name refers to a member class of the superclass of the class that contains the member class annotated actual.

extends super.Buffer()

The root class Anything defined in ceylon.language does not have a superclass.

The satisfies clause does double duty. It's used to specify that a class or interface is a direct subtype of one or more interfaces, and to specify upper bound type constraints applying to a type parameter.

SatisfiedTypes: "satisfies" PrimaryType ("&" PrimaryType)*

The satisfies clause may specify multiple types. If a satisfied type is a parameterized type, the satisfies clause must specify type arguments.

satisfies Sequence<Element> & Collection<Element>

Coverage is a strictly weaker relationship than assignability:

It follows that coverage obeys the identity property of assignability: a type covers itself. However, coverage does not obey the noncircularity property of assignability. It is possible to have distinct types A and B where A covers B and B covers A.

Case enumeration allows safe use of a type in a switch statement, or as the subject of the of operator. The compiler is able to statically validate that the switch contains an exhaustive list of all cases of the type, by checking that the union of cases enumerated in the switch covers the type, or that the second operand of of covers the type.

The of clause does triple duty. It's used to define self types and type families, enumerated types, and enumerated type constraints. The of clause may specify multiple types, called cases.

CaseTypes: "of" CaseType ("|" CaseType)*

CaseType: MemberName | PrimaryType

If an interface or abstract class with an of clause has exactly one case, and it is a type parameter of the interface or abstract class, or of the immediately containing type, if any, then that type parameter is a self type of the interface or abstract class, and:

shared abstract class Comparable<Other>() of Other 
        given Other satisfies Comparable<Other> {
    
    shared formal Integer compare(Other that);
    
    shared Integer reverseCompare(Other that) => that.compare(this) of Other;
    
}

Comparable<Item> comp = ... ;
Item item = comp of Item;

Otherwise, an interface or abstract class with an of clause may have multiple cases, but each case must be either:

Then the interface or abstract class is an enumerated type, and every subtype of the interface or abstract class must be a subtype of exactly one of the enumerated subtypes. A class or interface may not be a subtype of more than one case of an enumerated type.

of larger | smaller | equal

of Root<Element> | Leaf<Element> | Branch<Element>

A type parameter with an of clause may specify multiple cases, as defined in §3.5.3 Generic type constraints.

If a generic enumerated type X has a case type C, then C must directly extend or satisfy an instantiation Y of X, and for each type parameter T of X and corresponding argument A of T given in Y, either:

For example, the following covariant enumerated type is legal:

interface List<out Element> 
        of Cons<Element> | nil { ... }

class Cons<out Element>(Element element) 
        satisfies List<Element> { ... }

object nil 
        satisfies List<Nothing> { ... }

As is the following contravariant enumerated type:

interface Consumer<in Event> 
        of Logger | Handler<Event> 
        given Event satisfies AbstractEvent { ... }

interface Logger 
        satisfies Consumer<AbstractEvent> { ... }

interface Handler<in Event> 
        satisfies Consumer<AbstractEvent> 
        given Event satisfies AbstractEvent { ... }

But the following enumerated type is not legal, since it is possible to choose a legal argument T of the type parameter Type of Expression, such that the case types StringExpression and NumericExpression aren't subtypes of the instantiation Expression<T>:

interface Expression<out Type>
        of Function<Type> | String | Number { ... }

interface Function<out Type> 
        satisfies Expression<Type> { ... }

interface String 
        satisfies Expression<String> { ... }

interface Number 
        satisfies Expression<Integer|Float> { ... }

Two types are said to be disjoint if it is impossible to have a value that is an instance of both types. If X and Y are disjoint, then their intersection X&Y is the bottom type Nothing.

Two types X and Y are disjoint if either:

A type parameter allows a declaration to be abstracted over a constrained set of types.

TypeParameter: Variance? TypeName ("=" Type)

Every type parameter has a name and a variance.

Variance: "out" | "in"

A type parameter may, optionally, have a default type argument. A type parameter with a default type argument must occur after all type parameters without default type arguments in the type parameter list. The default type argument must satisfy the constraints on the type parameter.

A default type argument may not involve the parameter for which it is the default argument, nor any type parameter of the declaration that occurs later in the list of type parameters.

Within the body of the schema it parameterizes, a type parameter is itself a type. The type parameter is a subtype of every upper bound of the type parameter. However, a class or interface may not extend or satisfy a type parameter.

<Key, out Item>

<in Message>

<out Element=Object>

<in Left, in Right, out Result>

A covariant type parameter may only appear in covariant positions of the parameterized schema. A contravariant type parameter may only appear in contravariant positions of the parameterized schema. An invariant type parameter may appear in any position.

Furthermore, a type with a contravariant type parameter may only appear in a covariant position in an extended type, satisfied type, case type, or upper bound type constraint.

To determine if a type expression occurs in a covariant or contravariant position, we first consider how the type occurs syntactically.

For a generic function we examine the return type of the function, which is a covariant position.

For a generic type schema we examine each shared member, along with extended/satisfied types and case types.

In a shared method declaration of the parameterized type schema:

In a shared attribute declaration that is not variable:

In a shared reference declaration that is variable:

In a shared nested class declaration of the parameterized type schema:

In a shared nested interface declaration of the parameterized type schema:

For parameters of callable parameters, we first determine if the callable parameter itself is covariant or contravariant:

Then:

Finally, to determine if a type parameter that occurs as a type argument occurs in a covariant or contravariant position, we must consider the declared variance of the corresponding type parameter:

A parameterized method, class, or interface declaration may declare constraints upon ordinary type parameters using the given clause.

TypeConstraints: TypeConstraint+

There may be at most one given clause per type parameter.

TypeConstraint: "given" TypeName TypeConstraintInheritance

TypeConstraintInheritance: CaseTypes? SatisfiedTypes?

There are two different kinds of type constraint:

The types listed in an enumerated bound must be mutually disjoint, and each type must be a class or interface type.

A single given clause may specify multiple constraints on a certain type parameter. In particular, it may specify multiple upper bounds together with an enumerated bound. If multiple upper bounds are specified, at most one upper bound may be a class, and at most one upper bound may be a type parameter.

given Value satisfies Ordinal & Comparable<Value>

given Quantities satisfies Correspondence<Key,Decimal>

given Argument of String | Integer | Float

A type parameter is a subtype of its upper bounds.

class Holder<Value>(shared Value value) 
        extends Object
        given Value satisfies Object {
    shared actual Boolean equals(Object that) {
        if (is Holder<Value> that) {
            return value==that.value;
        }
        else {
            return false;
        }
    }
    shared actual Integer hash =>  value.hash;
}

Every type parameter has an implicit upper bound of type Anything.

An enumerated bound allows the use of an exhaustive switch with expressions of the parameter type.

Characters uppercase<Characters>(Characters chars) 
       given Characters of String | Range<Character> { 
    switch (Characters)
    case (satisfies String) { 
        return chars.uppercased;
    }
    case (satisfies Range<Character>) { 
        return chars.first.uppercased..chars.last.uppercased;
    }
}

given T abstracts One|Two

given T(Object arg)

A generic type constraint affects the type arguments that can be assigned to a type parameter:

A type argument list conforms to a type parameter list if, for every type parameter in the list, either:

There must be at least as many type parameters as type arguments. There must be at least as many type arguments as type parameters without default values.

If a type argument list conforms to a type parameter list, the combination of the parameterized type together with the type argument list is itself a type, called an applied type. We also call the applied type an instantiation of the generic type.

For a generic type X, the instantiations Y and Z of X represent the same type if and only if for every A in the list of type arguments specified in Y and corresponding B in the list of type arguments specified in Z, A is exactly the same type as B.

For a generic type X, and instantiations Y and Z of X, Y is a subtype of Z if and only if, for every type parameter T of X, and corresponding arguments A specified in Y and B specified in Z:

When a direct invocation expression, as defined by §6.6 Invocation expressions, for a generic function or a direct instantiation expression for a generic class does not explicitly specify type arguments, the type arguments are inferred from the argument expression types. The types of the argument expressions and the declared types of the corresponding parameters determine an inferred lower bound or inferred upper bound for each type parameter.

If a list of argument expressions has types A1,A2,... and the corresponding list of parameters has declared types P1,P2,..., the inferred lower bound for a type parameter T of the generic declaration is the conjunction of:

The inferred upper bound for a type parameter T of the generic declaration is the conjunction of:

Given types A and P, we determine the inferred lower bound A on P for T according to the nature of A and P:

Where:

Given types A and P, we determine the inferred upper bound A on P for T according to the nature of A and P:

Where:

The inferred type argument to a covariant or invariant type parameter T of the generic declaration is:

The inferred type argument to a contravariant type parameter T of the generic declaration is:

An argument expression with no type occurring in a dynamic block, as defined in §5.3.12 Dynamic blocks, may cause type argument inference to fail. When combining bounds using union, any constituent bound with no type results in a bound with no type. When combining bounds using intersection, any constituent bound with no type is eliminated. If the resulting inferred upper or lower bound has no type, type argument inference is impossible for the type argument, and type arguments must be specified explicitly.

If the inferred type argument does not satisfy the generic type constraints on T, a compilation error results.

Consider the following invocation:

[Element+] prepend<Element>(Element head, Element[] sequence) { ... }
value result = prepend(null, {"hello", "world"});

The inferred type of Element is the union type String?.

Now consider:

class Bag<out Element>(Element* elements) {
    shared Bag<ExtraElement> with<ExtraElement>(ExtraElement* elements) 
            given ExtraElement abstracts Element { ... }
}
Bag<String> bag = Bag("hello", "world");
value biggerBag = bag.with(1, 2, 5.0);

The inferred type of ExtraElement is the union type Integer|Float|String.

Finally consider:

interface Delegate<in Value> { ... }
class Consumer<in Value>(Delegate<Value>* delegates) { ... }
Delegate<String> delegate1 = ... ;
Delegate<Object> delegate2 = ... ; 
value consumer = Consumer(delegate1, delegate2);

The inferred type of Value is Consumer<String>.

For a generic type Y, inheritance produces subtypes with inherited instantiations of the generic type.

If a class or interface type X has the inherited instantiations V and W of some generic type Y, then:

Therefore, if a type X is a subtype of the instantiations V and W of some generic type Y, then either:

The following identities result from principal instantiation inheritance, for any generic type X<T>, and for any types A and B:

If a type X is a subtype of some instantiation V of a generic type Y, then, as a result of the principal instantiation inheritance restriction, we can form a unique instantiation of Y that is a subtype of every instantiation of Y to which X is assignable. We call this type the principal instantiation of Y for X.

We compute principal instantiations by making use of the identities observed above in §3.2.3 Union types, §3.2.4 Intersection types, and §3.7.2 Principal instantiation inheritance. For any generic type X:

A class or interface may declare an actual member with the same name as a member that it inherits from a supertype if the supertype member is declared formal or default. Then we say that the first member refines the second member, and it must obey restrictions defined in §4.5.6 Member class refinement, §4.7.8 Method refinement, or §4.8.7 Attribute refinement.

A declaration may not be annotated both formal and default.

If a declaration is annotated formal, default, or actual then it must also be annotated shared.

For any class or interface X, and for every declared or inherited member of X that is not refined by some other declared or inherited member of X, and for every other member declared or inherited by X that directly or indirectly refines a declaration that the first member itself directly or indirectly refines, the principal instantiation for X of the type that declares the first member must be a subtype of the principal instantiation for X of the type that declares the second member.

A type declaration that directly occurs in the body of another type is called a nested type. If a nested type is annotated shared, it may be used in a type expression outside the body in which it is declared, if and only if it occurs as a qualified type, as specified in §3.2.7 Type expressions.

The qualified types X.U and Y.V are exactly the same types if and only if U is exactly the same type as V, and in the case that this type is a member of a generic type Z, then the principal instantiation of Z for X is exactly the same type as the principal instantiation of Z for Y.

A qualified type X.U is a subtype of a qualified type Y.V if U is a subtype of V, and in the case that V is a member of a generic type Z, then X is a subtype of the principal instantiation of Z for Y.

Given a member declared by Y, and a declaration that refines it, we can construct a refined realization of the member or nested type:

Given an unqualified reference, as defined in §5.1.7 Unqualified reference resolution, to a declaration, and, in the case of a generic declaration, a list of type arguments for the type parameters of the declaration, we can construct an unqualified realization of the declaration:

Given a qualified reference, as defined in §5.1.8 Qualified reference resolution, with a qualifying type X, to a member or nested type declared by Y, and, in the case of a generic member or generic nested type, a list of type arguments for the type parameters of the member, we can construct a qualified realization of the member or nested type:

If, for any given qualified or unqualified reference, it is impossible to form the principal instantiation of the type that declares the referenced declaration, due to the hole described above in §3.7.3 Principal instantiation of a supertype, it is impossible to form a realization, and the reference to the declaration is illegal.