<commit_before># Classes and Objects

``` 
TmplDef          ::= [`case'] `class' ClassDef
                  |  [`case'] `object' ObjectDef
                  |  `trait' TraitDef
```

[Classes](#class-definitions) and [objects](#object-definitions)
are both defined in terms of _templates_.


## Templates

``` 
ClassTemplate   ::=  [EarlyDefs] ClassParents [TemplateBody]
TraitTemplate   ::=  [EarlyDefs] TraitParents [TemplateBody]
ClassParents    ::=  Constr {`with' AnnotType}
TraitParents    ::=  AnnotType {`with' AnnotType}
TemplateBody    ::=  [nl] `{' [SelfType] TemplateStat {semi TemplateStat} `}'
SelfType        ::=  id [`:' Type] `=>'
                 |   this `:' Type `=>'
```

A template defines the type signature, behavior and initial state of a
trait or class of objects or of a single object. Templates form part of
instance creation expressions, class definitions, and object
definitions.  A template 
`$sc$ with $mt_1$ with $\ldots$ with $mt_n$ { $\mathit{stats}$ }` 
consists of a constructor invocation $sc$
which defines the template's _superclass_, trait references
`$mt_1 , \ldots , mt_n$` $(n \geq 0)$, which define the
template's _traits_, and a statement sequence $\mathit{stats}$ which
contains initialization code and additional member definitions for the
template.

Each trait reference $mt_i$ must denote a [trait](#traits).
By contrast, the superclass constructor $sc$ normally refers to a
class which is not a trait. It is possible to write a list of
parents that starts with a trait reference, e.g.
`$mt_1$ with $\ldots$ with $mt_n$`. In that case the list
of parents is implicitly extended to include the supertype of $mt_1$
as first parent type. The new supertype must have at least one
constructor that does not take parameters.  In the following, we will
always assume that this implicit extension has been performed, so that
the first parent class of a template is a regular superclass
constructor, not a trait reference.

The list of parents of a template must be well-formed. This means that
the class denoted by the superclass constructor $sc$ must be a
subclass of the superclasses of all the traits $mt_1 , \ldots , mt_n$.
In other words, the non-trait classes inherited by a template form a
chain in the inheritance hierarchy which starts with the template's
superclass.

The _least proper supertype_ of a template is the class type or
[compound type](#compound-types) consisting of all its parent
class types. 

The statement sequence $\mathit{stats}$ contains member definitions that
define new members or overwrite members in the parent classes.  If the
template forms part of an abstract class or trait definition, the
statement part $\mathit{stats}$ may also contain declarations of abstract
members. If the template forms part of a concrete class definition,
$\mathit{stats}$ may still contain declarations of abstract type members, but
not of abstract term members.  Furthermore, $\mathit{stats}$ may in any case
also contain expressions; these are executed in the order they are
given as part of the initialization of a template.

The sequence of template statements may be prefixed with a formal
parameter definition and an arrow, e.g.\ `$x$ =>`, or
`$x$:$T$ =>`.  If a formal parameter is given, it can be
used as an alias for the reference `this` throughout the
body of the template.  
If the formal parameter comes with a type $T$, this definition affects
the _self type_ $S$ of the underlying class or object as follows:  Let $C$ be the type
of the class or trait or object defining the template.
If a type $T$ is given for the formal self parameter, $S$
is the greatest lower bound of $T$ and $C$.
If no type $T$ is given, $S$ is just $C$.
Inside the template, the type of `this` is assumed to be $S$.

The self type of a class or object must conform to the self types of
all classes which are inherited by the template $t$. 

A second form of self type annotation reads just 
`this: $S$ =>`. It prescribes the type $S$ for `this`
without introducing an alias name for it. 

###### Example
Consider the following class definitions:

```
class Base extends Object {}
trait Mixin extends Base {}
object O extends Mixin {}
```

In this case, the definition of `O` is expanded to:

```
object O extends Base with Mixin {}
```


<!-- TODO: Make all references to Java generic -->

**Inheriting from Java Types** \
A template may have a Java class as its superclass and Java interfaces as its
mixins. 

**Template Evaluation** \
Consider a template `$sc$ with $mt_1$ with $mt_n$ { $\mathit{stats}$ }`.

If this is the template of a [trait](#traits) then its _mixin-evaluation_ 
consists of an evaluation of the statement sequence $\mathit{stats}$.

If this is not a template of a trait, then its _evaluation_
consists of the following steps.

- First, the superclass constructor $sc$ is 
  [evaluated](#constructor-invocations).
- Then, all base classes in the template's [linearization](#class-linearization)
  up to the template's superclass denoted by $sc$ are
  mixin-evaluated. Mixin-evaluation happens in reverse order of
  occurrence in the linearization.
- Finally the statement sequence $\mathit{stats}\,$ is evaluated.


_Delayed Initializaton_ \
The initialization code of an object or class (but not a trait) that follows 
the superclass
constructor invocation and the mixin-evaluation of the template's base
classes is passed to a special hook, which is inaccessible from user
code. Normally, that hook simply executes the code that is passed to
it. But templates inheriting the `scala.DelayedInit` trait
can override the hook by re-implementing the `delayedInit`
method, which is defined as follows:

``` 
def delayedInit(body: => Unit)
```


### Constructor Invocations

``` 
Constr  ::=  AnnotType {`(' [Exprs] `)'}
```

Constructor invocations define the type, members, and initial state of
objects created by an instance creation expression, or of parts of an
object's definition which are inherited by a class or object
definition. A constructor invocation is a function application
`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)`, where $x$ is a 
[stable identifier](#paths), $c$ is a type name which either designates a
class or defines an alias type for one, $\mathit{targs}$ is a type argument
list, $\mathit{args}_1 , \ldots , \mathit{args}_n$ are argument lists, and there is a
constructor of that class which is [applicable](#function-applications)
to the given arguments. If the constructor invocation uses named or
default arguments, it is transformed into a block expression using the
same transformation as described [here](sec:named-default).

The prefix ``$x$.`' can be omitted.  A type argument list
can be given only if the class $c$ takes type parameters.  Even then
it can be omitted, in which case a type argument list is synthesized
using [local type inference](#local-type-inference). If no explicit
arguments are given, an empty list `()` is implicitly supplied.

An evaluation of a constructor invocation 
`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)`
consists of the following steps:

- First, the prefix $x$ is evaluated.
- Then, the arguments $\mathit{args}_1 , \ldots , \mathit{args}_n$ are evaluated from 
  left to right.
- Finally, the class being constructed is initialized by evaluating the
  template of the class referred to by $c$.

### Class Linearization

The classes reachable through transitive closure of the direct
inheritance relation from a class $C$ are called the _base classes_ of $C$.  Because of mixins, the inheritance relationship
on base classes forms in general a directed acyclic graph. A
linearization of this graph is defined as follows.


###### Definition: linearization
Let $C$ be a class with template
`$C_1$ with ... with $C_n$ { $\mathit{stats}$ }`.
The _linearization_ of $C$, $\mathcal{L}(C)$ is defined as follows:

$\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1)$

Here $\vec{+}$ denotes concatenation where elements of the right operand
replace identical elements of the left operand:

```
\[
\begin{array}{lcll}
\{a, A\} \;\vec{+}\; B &=& a, (A \;\vec{+}\; B)  &{\bf if} \; a \not\in B \\
                       &=& A \;\vec{+}\; B       &{\bf if} \; a \in B
\end{array}
\]
```


###### Example
Consider the following class definitions.

```
abstract class AbsIterator extends AnyRef { ... }
trait RichIterator extends AbsIterator { ... }
class StringIterator extends AbsIterator { ... }
class Iter extends StringIterator with RichIterator { ... }
```

Then the linearization of class `Iter` is

```
{ Iter, RichIterator, StringIterator, AbsIterator, AnyRef, Any }
```

Note that the linearization of a class refines the inheritance
relation: if $C$ is a subclass of $D$, then $C$ precedes $D$ in any
linearization where both $C$ and $D$ occur.
[Linearization](#definition-linearization) also satisfies the property that
a linearization of a class always contains the linearization of its direct superclass as a suffix.

For instance, the linearization of `StringIterator` is

```
{ StringIterator, AbsIterator, AnyRef, Any }
```

which is a suffix of the linearization of its subclass `Iter`.
The same is not true for the linearization of mixins.
For instance, the linearization of `RichIterator` is

```
{ RichIterator, AbsIterator, AnyRef, Any }
```

which is not a suffix of the linearization of `Iter`.


### Class Members

A class $C$ defined by a template `$C_1$ with $\ldots$ with $C_n$ { $\mathit{stats}$ }`
can define members in its statement sequence
$\mathit{stats}$ and can inherit members from all parent classes.  Scala
adopts Java and C\#'s conventions for static overloading of
methods. It is thus possible that a class defines and/or inherits
several methods with the same name.  To decide whether a defined
member of a class $C$ overrides a member of a parent class, or whether
the two co-exist as overloaded variants in $C$, Scala uses the
following definition of _matching_ on members:

###### Definition: matching
A member definition $M$ _matches_ a member definition $M'$, if $M$
and $M'$ bind the same name, and one of following holds.

1. Neither $M$ nor $M'$ is a method definition.
2. $M$ and $M'$ define both monomorphic methods with equivalent argument types.
3. $M$ defines a parameterless method and $M'$ defines a method
   with an empty parameter list `()` or _vice versa_.
4. $M$ and $M'$ define both polymorphic methods with
   equal number of argument types $\overline T$, $\overline T'$
   and equal numbers of type parameters
   $\overline t$, $\overline t'$, say, and  $\overline T' = [\overline t'/\overline t]\overline T$.

<!--
every argument type
$T_i$ of $M$ is equal to the corresponding argument type $T`_i$ of
$M`$ where every occurrence of a type parameter $t`$ of $M`$ has been replaced by the corresponding type parameter $t$ of $M$.
-->

Member definitions fall into two categories: concrete and abstract.
Members of class $C$ are either _directly defined_ (i.e.\ they appear in
$C$'s statement sequence $\mathit{stats}$) or they are _inherited_.  There are two rules
that determine the set of members of a class, one for each category:

A _concrete member_ of a class $C$ is any concrete definition $M$ in
some class $C_i \in \mathcal{L}(C)$, except if there is a preceding class
$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines a concrete
member $M'$ matching $M$.

An _abstract member_ of a class $C$ is any abstract definition $M$
in some class $C_i \in \mathcal{L}(C)$, except if $C$ contains already a
concrete member $M'$ matching $M$, or if there is a preceding class
$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines an abstract
member $M'$ matching $M$.

This definition also determines the [overriding](#overriding) relationships
between matching members of a class $C$ and its parents.  
First, a concrete definition always overrides an abstract definition. 
Second, for definitions $M$ and $M$' which are both concrete or both abstract,
$M$ overrides $M'$ if $M$ appears in a class that precedes (in the
linearization of $C$) the class in which $M'$ is defined.

It is an error if a template directly defines two matching members. It
is also an error if a template contains two members (directly defined
or inherited) with the same name and the same [erased type](#type-erasure).
Finally, a template is not allowed to contain two methods (directly
defined or inherited) with the same name which both define default arguments.


###### Example
Consider the trait definitions:

```
trait A { def f: Int }
trait B extends A { def f: Int = 1 ; def g: Int = 2 ; def h: Int = 3 }
trait C extends A { override def f: Int = 4 ; def g: Int }
trait D extends B with C { def h: Int }
```

Then trait `D` has a directly defined abstract member `h`. It
inherits member `f` from trait `C` and member `g` from
trait `B`.


### Overriding

<!-- TODO: Explain that classes cannot override each other -->

A member $M$ of class $C$ that [matches](#class-members) 
a non-private member $M'$ of a
base class of $C$ is said to _override_ that member.  In this case
the binding of the overriding member $M$ must [subsume](#conformance)
the binding of the overridden member $M'$.
Furthermore, the following restrictions on modifiers apply to $M$ and
$M'$:

- $M'$ must not be labeled `final`.
- $M$ must not be [`private`](#modifiers).
- If $M$ is labeled `private[$C$]` for some enclosing class or package $C$,
  then $M'$ must be labeled `private[$C'$]` for some class or package $C'$ where
  $C'$ equals $C$ or $C'$ is contained in $C$.
  <!-- TODO: check whether this is accurate -->
- If $M$ is labeled `protected`, then $M'$ must also be
  labeled `protected`.
- If $M'$ is not an abstract member, then $M$ must be labeled `override`.
  Furthermore, one of two possibilities must hold:
    - either $M$ is defined in a subclass of the class where is $M'$ is defined, 
    - or both $M$ and $M'$ override a third member $M''$ which is defined
      in a base class of both the classes containing $M$ and $M'$ 
- If $M'$ is [incomplete](#modifiers) in $C$ then $M$ must be
  labeled `abstract override`.
- If $M$ and $M'$ are both concrete value definitions, then either none
  of them is marked `lazy` or both must be marked `lazy`.

A special rule concerns parameterless methods. If a paramterless
method defined as `def $f$: $T$ = ...` or `def $f$ = ...` overrides a method of
type $()T'$ which has an empty parameter list, then $f$ is also
assumed to have an empty parameter list.

Another restriction applies to abstract type members: An abstract type
member with a [volatile type](#volatile-types) as its upper
bound may not override an abstract type member which does not have a
volatile upper bound.

An overriding method inherits all default arguments from the definition
in the superclass. By specifying default arguments in the overriding method
it is possible to add new defaults (if the corresponding parameter in the<commit_msg>SI-6195 stable members can only be overridden by stable members<commit_after># Classes and Objects

``` 
TmplDef          ::= [`case'] `class' ClassDef
                  |  [`case'] `object' ObjectDef
                  |  `trait' TraitDef
```

[Classes](#class-definitions) and [objects](#object-definitions)
are both defined in terms of _templates_.


## Templates

``` 
ClassTemplate   ::=  [EarlyDefs] ClassParents [TemplateBody]
TraitTemplate   ::=  [EarlyDefs] TraitParents [TemplateBody]
ClassParents    ::=  Constr {`with' AnnotType}
TraitParents    ::=  AnnotType {`with' AnnotType}
TemplateBody    ::=  [nl] `{' [SelfType] TemplateStat {semi TemplateStat} `}'
SelfType        ::=  id [`:' Type] `=>'
                 |   this `:' Type `=>'
```

A template defines the type signature, behavior and initial state of a
trait or class of objects or of a single object. Templates form part of
instance creation expressions, class definitions, and object
definitions.  A template 
`$sc$ with $mt_1$ with $\ldots$ with $mt_n$ { $\mathit{stats}$ }` 
consists of a constructor invocation $sc$
which defines the template's _superclass_, trait references
`$mt_1 , \ldots , mt_n$` $(n \geq 0)$, which define the
template's _traits_, and a statement sequence $\mathit{stats}$ which
contains initialization code and additional member definitions for the
template.

Each trait reference $mt_i$ must denote a [trait](#traits).
By contrast, the superclass constructor $sc$ normally refers to a
class which is not a trait. It is possible to write a list of
parents that starts with a trait reference, e.g.
`$mt_1$ with $\ldots$ with $mt_n$`. In that case the list
of parents is implicitly extended to include the supertype of $mt_1$
as first parent type. The new supertype must have at least one
constructor that does not take parameters.  In the following, we will
always assume that this implicit extension has been performed, so that
the first parent class of a template is a regular superclass
constructor, not a trait reference.

The list of parents of a template must be well-formed. This means that
the class denoted by the superclass constructor $sc$ must be a
subclass of the superclasses of all the traits $mt_1 , \ldots , mt_n$.
In other words, the non-trait classes inherited by a template form a
chain in the inheritance hierarchy which starts with the template's
superclass.

The _least proper supertype_ of a template is the class type or
[compound type](#compound-types) consisting of all its parent
class types. 

The statement sequence $\mathit{stats}$ contains member definitions that
define new members or overwrite members in the parent classes.  If the
template forms part of an abstract class or trait definition, the
statement part $\mathit{stats}$ may also contain declarations of abstract
members. If the template forms part of a concrete class definition,
$\mathit{stats}$ may still contain declarations of abstract type members, but
not of abstract term members.  Furthermore, $\mathit{stats}$ may in any case
also contain expressions; these are executed in the order they are
given as part of the initialization of a template.

The sequence of template statements may be prefixed with a formal
parameter definition and an arrow, e.g.\ `$x$ =>`, or
`$x$:$T$ =>`.  If a formal parameter is given, it can be
used as an alias for the reference `this` throughout the
body of the template.  
If the formal parameter comes with a type $T$, this definition affects
the _self type_ $S$ of the underlying class or object as follows:  Let $C$ be the type
of the class or trait or object defining the template.
If a type $T$ is given for the formal self parameter, $S$
is the greatest lower bound of $T$ and $C$.
If no type $T$ is given, $S$ is just $C$.
Inside the template, the type of `this` is assumed to be $S$.

The self type of a class or object must conform to the self types of
all classes which are inherited by the template $t$. 

A second form of self type annotation reads just 
`this: $S$ =>`. It prescribes the type $S$ for `this`
without introducing an alias name for it. 

###### Example
Consider the following class definitions:

```
class Base extends Object {}
trait Mixin extends Base {}
object O extends Mixin {}
```

In this case, the definition of `O` is expanded to:

```
object O extends Base with Mixin {}
```


<!-- TODO: Make all references to Java generic -->

**Inheriting from Java Types** \
A template may have a Java class as its superclass and Java interfaces as its
mixins. 

**Template Evaluation** \
Consider a template `$sc$ with $mt_1$ with $mt_n$ { $\mathit{stats}$ }`.

If this is the template of a [trait](#traits) then its _mixin-evaluation_ 
consists of an evaluation of the statement sequence $\mathit{stats}$.

If this is not a template of a trait, then its _evaluation_
consists of the following steps.

- First, the superclass constructor $sc$ is 
  [evaluated](#constructor-invocations).
- Then, all base classes in the template's [linearization](#class-linearization)
  up to the template's superclass denoted by $sc$ are
  mixin-evaluated. Mixin-evaluation happens in reverse order of
  occurrence in the linearization.
- Finally the statement sequence $\mathit{stats}\,$ is evaluated.


_Delayed Initializaton_ \
The initialization code of an object or class (but not a trait) that follows 
the superclass
constructor invocation and the mixin-evaluation of the template's base
classes is passed to a special hook, which is inaccessible from user
code. Normally, that hook simply executes the code that is passed to
it. But templates inheriting the `scala.DelayedInit` trait
can override the hook by re-implementing the `delayedInit`
method, which is defined as follows:

``` 
def delayedInit(body: => Unit)
```


### Constructor Invocations

``` 
Constr  ::=  AnnotType {`(' [Exprs] `)'}
```

Constructor invocations define the type, members, and initial state of
objects created by an instance creation expression, or of parts of an
object's definition which are inherited by a class or object
definition. A constructor invocation is a function application
`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)`, where $x$ is a 
[stable identifier](#paths), $c$ is a type name which either designates a
class or defines an alias type for one, $\mathit{targs}$ is a type argument
list, $\mathit{args}_1 , \ldots , \mathit{args}_n$ are argument lists, and there is a
constructor of that class which is [applicable](#function-applications)
to the given arguments. If the constructor invocation uses named or
default arguments, it is transformed into a block expression using the
same transformation as described [here](sec:named-default).

The prefix ``$x$.`' can be omitted.  A type argument list
can be given only if the class $c$ takes type parameters.  Even then
it can be omitted, in which case a type argument list is synthesized
using [local type inference](#local-type-inference). If no explicit
arguments are given, an empty list `()` is implicitly supplied.

An evaluation of a constructor invocation 
`$x$.$c$[$\mathit{targs}$]($\mathit{args}_1$)$\ldots$($\mathit{args}_n$)`
consists of the following steps:

- First, the prefix $x$ is evaluated.
- Then, the arguments $\mathit{args}_1 , \ldots , \mathit{args}_n$ are evaluated from 
  left to right.
- Finally, the class being constructed is initialized by evaluating the
  template of the class referred to by $c$.

### Class Linearization

The classes reachable through transitive closure of the direct
inheritance relation from a class $C$ are called the _base classes_ of $C$.  Because of mixins, the inheritance relationship
on base classes forms in general a directed acyclic graph. A
linearization of this graph is defined as follows.


###### Definition: linearization
Let $C$ be a class with template
`$C_1$ with ... with $C_n$ { $\mathit{stats}$ }`.
The _linearization_ of $C$, $\mathcal{L}(C)$ is defined as follows:

$\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1)$

Here $\vec{+}$ denotes concatenation where elements of the right operand
replace identical elements of the left operand:

```
\[
\begin{array}{lcll}
\{a, A\} \;\vec{+}\; B &=& a, (A \;\vec{+}\; B)  &{\bf if} \; a \not\in B \\
                       &=& A \;\vec{+}\; B       &{\bf if} \; a \in B
\end{array}
\]
```


###### Example
Consider the following class definitions.

```
abstract class AbsIterator extends AnyRef { ... }
trait RichIterator extends AbsIterator { ... }
class StringIterator extends AbsIterator { ... }
class Iter extends StringIterator with RichIterator { ... }
```

Then the linearization of class `Iter` is

```
{ Iter, RichIterator, StringIterator, AbsIterator, AnyRef, Any }
```

Note that the linearization of a class refines the inheritance
relation: if $C$ is a subclass of $D$, then $C$ precedes $D$ in any
linearization where both $C$ and $D$ occur.
[Linearization](#definition-linearization) also satisfies the property that
a linearization of a class always contains the linearization of its direct superclass as a suffix.

For instance, the linearization of `StringIterator` is

```
{ StringIterator, AbsIterator, AnyRef, Any }
```

which is a suffix of the linearization of its subclass `Iter`.
The same is not true for the linearization of mixins.
For instance, the linearization of `RichIterator` is

```
{ RichIterator, AbsIterator, AnyRef, Any }
```

which is not a suffix of the linearization of `Iter`.


### Class Members

A class $C$ defined by a template `$C_1$ with $\ldots$ with $C_n$ { $\mathit{stats}$ }`
can define members in its statement sequence
$\mathit{stats}$ and can inherit members from all parent classes.  Scala
adopts Java and C\#'s conventions for static overloading of
methods. It is thus possible that a class defines and/or inherits
several methods with the same name.  To decide whether a defined
member of a class $C$ overrides a member of a parent class, or whether
the two co-exist as overloaded variants in $C$, Scala uses the
following definition of _matching_ on members:

###### Definition: matching
A member definition $M$ _matches_ a member definition $M'$, if $M$
and $M'$ bind the same name, and one of following holds.

1. Neither $M$ nor $M'$ is a method definition.
2. $M$ and $M'$ define both monomorphic methods with equivalent argument types.
3. $M$ defines a parameterless method and $M'$ defines a method
   with an empty parameter list `()` or _vice versa_.
4. $M$ and $M'$ define both polymorphic methods with
   equal number of argument types $\overline T$, $\overline T'$
   and equal numbers of type parameters
   $\overline t$, $\overline t'$, say, and  $\overline T' = [\overline t'/\overline t]\overline T$.

<!--
every argument type
$T_i$ of $M$ is equal to the corresponding argument type $T`_i$ of
$M`$ where every occurrence of a type parameter $t`$ of $M`$ has been replaced by the corresponding type parameter $t$ of $M$.
-->

Member definitions fall into two categories: concrete and abstract.
Members of class $C$ are either _directly defined_ (i.e.\ they appear in
$C$'s statement sequence $\mathit{stats}$) or they are _inherited_.  There are two rules
that determine the set of members of a class, one for each category:

A _concrete member_ of a class $C$ is any concrete definition $M$ in
some class $C_i \in \mathcal{L}(C)$, except if there is a preceding class
$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines a concrete
member $M'$ matching $M$.

An _abstract member_ of a class $C$ is any abstract definition $M$
in some class $C_i \in \mathcal{L}(C)$, except if $C$ contains already a
concrete member $M'$ matching $M$, or if there is a preceding class
$C_j \in \mathcal{L}(C)$ where $j < i$ which directly defines an abstract
member $M'$ matching $M$.

This definition also determines the [overriding](#overriding) relationships
between matching members of a class $C$ and its parents.  
First, a concrete definition always overrides an abstract definition. 
Second, for definitions $M$ and $M$' which are both concrete or both abstract,
$M$ overrides $M'$ if $M$ appears in a class that precedes (in the
linearization of $C$) the class in which $M'$ is defined.

It is an error if a template directly defines two matching members. It
is also an error if a template contains two members (directly defined
or inherited) with the same name and the same [erased type](#type-erasure).
Finally, a template is not allowed to contain two methods (directly
defined or inherited) with the same name which both define default arguments.


###### Example
Consider the trait definitions:

```
trait A { def f: Int }
trait B extends A { def f: Int = 1 ; def g: Int = 2 ; def h: Int = 3 }
trait C extends A { override def f: Int = 4 ; def g: Int }
trait D extends B with C { def h: Int }
```

Then trait `D` has a directly defined abstract member `h`. It
inherits member `f` from trait `C` and member `g` from
trait `B`.


### Overriding

<!-- TODO: Explain that classes cannot override each other -->

A member $M$ of class $C$ that [matches](#class-members) 
a non-private member $M'$ of a
base class of $C$ is said to _override_ that member.  In this case
the binding of the overriding member $M$ must [subsume](#conformance)
the binding of the overridden member $M'$.
Furthermore, the following restrictions on modifiers apply to $M$ and
$M'$:

- $M'$ must not be labeled `final`.
- $M$ must not be [`private`](#modifiers).
- If $M$ is labeled `private[$C$]` for some enclosing class or package $C$,
  then $M'$ must be labeled `private[$C'$]` for some class or package $C'$ where
  $C'$ equals $C$ or $C'$ is contained in $C$.
  <!-- TODO: check whether this is accurate -->
- If $M$ is labeled `protected`, then $M'$ must also be
  labeled `protected`.
- If $M'$ is not an abstract member, then $M$ must be labeled `override`.
  Furthermore, one of two possibilities must hold:
    - either $M$ is defined in a subclass of the class where is $M'$ is defined, 
    - or both $M$ and $M'$ override a third member $M''$ which is defined
      in a base class of both the classes containing $M$ and $M'$ 
- If $M'$ is [incomplete](#modifiers) in $C$ then $M$ must be
  labeled `abstract override`.
- If $M$ and $M'$ are both concrete value definitions, then either none
  of them is marked `lazy` or both must be marked `lazy`.

A stable member can only be overridden by a stable member.
For example, this is not allowed:

```
class X { val stable = 1}
class Y extends X { override var stable = 1 } // error
```

Another restriction applies to abstract type members: An abstract type
member with a [volatile type](#volatile-types) as its upper
bound may not override an abstract type member which does not have a
volatile upper bound.

A special rule concerns parameterless methods. If a parameterless
method defined as `def $f$: $T$ = ...` or `def $f$ = ...` overrides a method of
type $()T'$ which has an empty parameter list, then $f$ is also
assumed to have an empty parameter list.

An overriding method inherits all default arguments from the definition
in the superclass. By specifying default arguments in the overriding method
it is possible to add new defaults (if the corresponding parameter in the
{'fraction_non_alphanumeric': 0.09758992449968679, 'fraction_numerical': 0.0016484784543866011, 'mean_word_length': 4.162893617021276, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 23, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '206692', 'n_tokens_mistral': 8675, 'n_tokens_neox': 8290, 'n_words': 4419}