# Expressions

Expressions are composed of operators and operands. Expression forms are discussed subsequently in decreasing order of precedence.

## Expression Typing

The typing of expressions is often relative to some expected type (which might be undefined). When we write "expression $e$ is expected to conform to type $T$", we mean:

1. the expected type of $e$ is $T$, and
2. the type of expression $e$ must conform to $T$.

The following skolemization rule is applied universally for every expression: If the type of an expression would be an existential type $T$, then the type of the expression is assumed instead to be a skolemization of $T$.

Skolemization is reversed by type packing. Assume an expression $e$ of type $T$ and let $t_1[\mathit{tps}_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}_n] >: L_n <: U_n$ be all the type variables created by skolemization of some part of $e$ which are free in $T$. Then the packed type of $e$ is

## Literals

Typing of literals is as described here; their evaluation is immediate.

## The Null Value

The null value is of type scala.Null, and thus conforms to every reference type. It denotes a reference value which refers to a special null object. This object implements methods in class scala.AnyRef as follows:

• eq($x\,$) and ==($x\,$) return true iff the argument $x$ is also the "null" object.
• ne($x\,$) and !=($x\,$) return true iff the argument x is not also the "null" object.
• isInstanceOf[$T\,$] always returns false.
• asInstanceOf[$T\,$] returns the default value of type $T$.
• ## returns 0.

A reference to any other member of the "null" object causes a NullPointerException to be thrown.

## Designators

A designator refers to a named term. It can be a simple name or a selection.

A simple name $x$ refers to a value as specified here. If $x$ is bound by a definition or declaration in an enclosing class or object $C$, it is taken to be equivalent to the selection $C$.this.$x$ where $C$ is taken to refer to the class containing $x$ even if the type name $C$ is shadowed at the occurrence of $x$.

If $r$ is a stable identifier of type $T$, the selection $r.x$ refers statically to a term member $m$ of $r$ that is identified in $T$ by the name $x$.

For other expressions $e$, $e.x$ is typed as if it was { val $y$ = $e$; $y$.$x$ }, for some fresh name $y$.

The expected type of a designator's prefix is always undefined. The type of a designator is the type $T$ of the entity it refers to, with the following exception: The type of a path $p$ which occurs in a context where a stable type is required is the singleton type $p$.type.

The contexts where a stable type is required are those that satisfy one of the following conditions:

1. The path $p$ occurs as the prefix of a selection and it does not designate a constant, or
2. The expected type $\mathit{pt}$ is a stable type, or
3. The expected type $\mathit{pt}$ is an abstract type with a stable type as lower bound, and the type $T$ of the entity referred to by $p$ does not conform to $\mathit{pt}$, or
4. The path $p$ designates a module.

The selection $e.x$ is evaluated by first evaluating the qualifier expression $e$, which yields an object $r$, say. The selection's result is then the member of $r$ that is either defined by $m$ or defined by a definition overriding $m$.

## This and Super

The expression this can appear in the statement part of a template or compound type. It stands for the object being defined by the innermost template or compound type enclosing the reference. If this is a compound type, the type of this is that compound type. If it is a template of a class or object definition with simple name $C$, the type of this is the same as the type of $C$.this.

The expression $C$.this is legal in the statement part of an enclosing class or object definition with simple name $C$. It stands for the object being defined by the innermost such definition. If the expression's expected type is a stable type, or $C$.this occurs as the prefix of a selection, its type is $C$.this.type, otherwise it is the self type of class $C$.

A reference super.$m$ refers statically to a method or type $m$ in the least proper supertype of the innermost template containing the reference. It evaluates to the member $m'$ in the actual supertype of that template which is equal to $m$ or which overrides $m$. The statically referenced member $m$ must be a type or a method.

If it is a method, it must be concrete, or the template containing the reference must have a member $m'$ which overrides $m$ and which is labeled abstract override.

A reference $C$.super.$m$ refers statically to a method or type $m$ in the least proper supertype of the innermost enclosing class or object definition named $C$ which encloses the reference. It evaluates to the member $m'$ in the actual supertype of that class or object which is equal to $m$ or which overrides $m$. The statically referenced member $m$ must be a type or a method. If the statically referenced member $m$ is a method, it must be concrete, or the innermost enclosing class or object definition named $C$ must have a member $m'$ which overrides $m$ and which is labeled abstract override.

The super prefix may be followed by a trait qualifier [$T\,$], as in $C$.super[$T\,$].$x$. This is called a static super reference. In this case, the reference is to the type or method of $x$ in the parent trait of $C$ whose simple name is $T$. That member must be uniquely defined. If it is a method, it must be concrete.

###### Example

Consider the following class definitions

The linearization of class C is {C, B, Root} and the linearization of class D is {D, B, A, Root}. Then we have:

Note that the superB function returns different results depending on whether B is mixed in with class Root or A.

## Function Applications

An application $f(e_1 , \ldots , e_m)$ applies the function $f$ to the argument expressions $e_1, \ldots , e_m$. For this expression to be well-typed, the function must be applicable to its arguments, which is defined next by case analysis on $f$'s type.

If $f$ has a method type ($p_1$:$T_1 , \ldots , p_n$:$T_n$)$U$, each argument expression $e_i$ is typed with the corresponding parameter type $T_i$ as expected type. Let $S_i$ be the type of argument $e_i$ $(i = 1 , \ldots , m)$. The function $f$ must be applicable to its arguments $e_1, \ldots , e_n$ of types $S_1 , \ldots , S_n$. We say that an argument expression $e_i$ is a named argument if it has the form $x_i=e'_i$ and $x_i$ is one of the parameter names $p_1, \ldots, p_n$.

Once the types $S_i$ have been determined, the function $f$ of the above method type is said to be applicable if all of the following conditions hold:

• for every named argument $p_j=e_i'$ the type $S_i$ is compatible with the parameter type $T_j$;
• for every positional argument $e_i$ the type $S_i$ is compatible with $T_i$;
• if the expected type is defined, the result type $U$ is compatible to it.

If $f$ is a polymorphic method, local type inference is used to instantiate $f$'s type parameters. The polymorphic method is applicable if type inference can determine type arguments so that the instantiated method is applicable.

If $f$ has some value type, the application is taken to be equivalent to $f$.apply($e_1 , \ldots , e_m$), i.e. the application of an apply method defined by $f$. The value $f$ is applicable to the given arguments if $f$.apply is applicable.

Evaluation of $f$($e_1 , \ldots , e_n$) usually entails evaluation of $f$ and $e_1 , \ldots , e_n$ in that order. Each argument expression is converted to the type of its corresponding formal parameter. After that, the application is rewritten to the function's right hand side, with actual arguments substituted for formal parameters. The result of evaluating the rewritten right-hand side is finally converted to the function's declared result type, if one is given.

The case of a formal parameter with a parameterless method type =>$T$ is treated specially. In this case, the corresponding actual argument expression $e$ is not evaluated before the application. Instead, every use of the formal parameter on the right-hand side of the rewrite rule entails a re-evaluation of $e$. In other words, the evaluation order for =>-parameters is call-by-name whereas the evaluation order for normal parameters is call-by-value. Furthermore, it is required that $e$'s packed type conforms to the parameter type $T$. The behavior of by-name parameters is preserved if the application is transformed into a block due to named or default arguments. In this case, the local value for that parameter has the form val $y_i$ = () => $e$ and the argument passed to the function is $y_i$().

The last argument in an application may be marked as a sequence argument, e.g. $e$: _*. Such an argument must correspond to a repeated parameter of type $S$* and it must be the only argument matching this parameter (i.e. the number of formal parameters and actual arguments must be the same). Furthermore, the type of $e$ must conform to scala.Seq[$T$], for some type $T$ which conforms to $S$. In this case, the argument list is transformed by replacing the sequence $e$ with its elements. When the application uses named arguments, the vararg parameter has to be specified exactly once.

A function application usually allocates a new frame on the program's run-time stack. However, if a local function or a final method calls itself as its last action, the call is executed using the stack-frame of the caller.

###### Example

Assume the following function which computes the sum of a variable number of arguments:

Then

both yield 10 as result. On the other hand,

would not typecheck.

### Named and Default Arguments

If an application might uses named arguments $p = e$ or default arguments, the following conditions must hold.

• For every named argument $p_i = e_i$ which appears left of a positional argument in the argument list $e_1 \ldots e_m$, the argument position $i$ coincides with the position of parameter $p_i$ in the parameter list of the applied function.
• The names $x_i$ of all named arguments are pairwise distinct and no named argument defines a parameter which is already specified by a positional argument.
• Every formal parameter $p_j:T_j$ which is not specified by either a positional or a named argument has a default argument.

If the application uses named or default arguments the following transformation is applied to convert it into an application without named or default arguments.

If the function $f$ has the form $p.m$[$\mathit{targs}$] it is transformed into the block

If the function $f$ is itself an application expression the transformation is applied recursively on $f$. The result of transforming $f$ is a block of the form

where every argument in $(\mathit{args}_1) , \ldots , (\mathit{args}_l)$ is a reference to one of the values $x_1 , \ldots , x_k$. To integrate the current application into the block, first a value definition using a fresh name $y_i$ is created for every argument in $e_1 , \ldots , e_m$, which is initialised to $e_i$ for positional arguments and to $e'_i$ for named arguments of the form $x_i=e'_i$. Then, for every parameter which is not specified by the argument list, a value definition using a fresh name $z_i$ is created, which is initialized using the method computing the default argument of this parameter.

Let $\mathit{args}$ be a permutation of the generated names $y_i$ and $z_i$ such such that the position of each name matches the position of its corresponding parameter in the method type ($p_1:T_1 , \ldots , p_n:T_n$)$U$. The final result of the transformation is a block of the form

### Signature Polymorphic Methods

For invocations of signature polymorphic methods of the target platform $f$($e_1 , \ldots , e_m$), the invoked function has a different method type ($p_1$:$T_1 , \ldots , p_n$:$T_n$)$U$ at each call site. The parameter types $T_ , \ldots , T_n$ are the types of the argument expressions $e_1 , \ldots , e_m$ and $U$ is the expected type at the call site. If the expected type is undefined then $U$ is scala.AnyRef. The parameter names $p_1 , \ldots , p_n$ are fresh.

###### Note

On the Java platform version 7 and later, the methods invoke and invokeExact in class java.lang.invoke.MethodHandle are signature polymorphic.

## Method Values

The expression $e$ _ is well-formed if $e$ is of method type or if $e$ is a call-by-name parameter. If $e$ is a method with parameters, $e$ _ represents $e$ converted to a function type by eta expansion. If $e$ is a parameterless method or call-by-name parameter of type =>$T$, $e$ _ represents the function of type () => $T$, which evaluates $e$ when it is applied to the empty parameterlist ().

###### Example

The method values in the left column are each equivalent to the eta-expanded expressions on the right.

placeholder syntax eta-expansion
math.sin _ x => math.sin(x)
math.pow _ (x1, x2) => math.pow(x1, x2)
val vs = 1 to 9; vs.fold _ (z) => (op) => vs.fold(z)(op)
(1 to 9).fold(z)_ { val eta1 = z; val eta2 = 1 to 9; op => eta2.fold(eta1)(op) }
Some(1).fold(??? : Int)_ { val eta1 = () => ???; val eta2 = Some(1); op => eta2.fold(eta1())(op) }

Note that a space is necessary between a method name and the trailing underscore because otherwise the underscore would be considered part of the name.

## Type Applications

A type application $e$[$T_1 , \ldots , T_n$] instantiates a polymorphic value $e$ of type [$a_1$ >: $L_1$ <: $U_1, \ldots , a_n$ >: $L_n$ <: $U_n$]$S$ with argument types $T_1 , \ldots , T_n$. Every argument type $T_i$ must obey the corresponding bounds $L_i$ and $U_i$. That is, for each $i = 1 , \ldots , n$, we must have $\sigma L_i <: T_i <: \sigma U_i$, where $\sigma$ is the substitution $[a_1 := T_1 , \ldots , a_n := T_n]$. The type of the application is $\sigma S$.

If the function part $e$ is of some value type, the type application is taken to be equivalent to $e$.apply[$T_1 , \ldots ,$ T$_n$], i.e. the application of an apply method defined by $e$.

Type applications can be omitted if local type inference can infer best type parameters for a polymorphic functions from the types of the actual function arguments and the expected result type.

## Tuples

A tuple expression ($e_1 , \ldots , e_n$) is an alias for the class instance creation scala.Tuple$n$($e_1 , \ldots , e_n$), where $n \geq 2$. The empty tuple () is the unique value of type scala.Unit.

## Instance Creation Expressions

A simple instance creation expression is of the form new $c$ where $c$ is a constructor invocation. Let $T$ be the type of $c$. Then $T$ must denote a (a type instance of) a non-abstract subclass of scala.AnyRef. Furthermore, the concrete self type of the expression must conform to the self type of the class denoted by $T$. The concrete self type is normally $T$, except if the expression new $c$ appears as the right hand side of a value definition

(where the type annotation : $S$ may be missing). In the latter case, the concrete self type of the expression is the compound type $T$ with $x$.type.

The expression is evaluated by creating a fresh object of type $T$ which is initialized by evaluating $c$. The type of the expression is $T$.

A general instance creation expression is of the form new $t$ for some class template $t$. Such an expression is equivalent to the block

where $a$ is a fresh name of an anonymous class which is inaccessible to user programs.

There is also a shorthand form for creating values of structural types: If {$D$} is a class body, then new {$D$} is equivalent to the general instance creation expression new AnyRef{$D$}.

###### Example

Consider the following structural instance creation expression:

This is a shorthand for the general instance creation expression

The latter is in turn a shorthand for the block