Make Null act like the bottom type for all the (default nullable) types.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \usepackage[T1]{fontenc}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
@@ skipping 2598 matching lines @@
 {\bf nullLiteral:}
       \NULL{}
 .
 \end{grammar}
 
 \LMHash{}
 The null object is the sole instance of the built-in class \code{Null}. Attempting to instantiate \code{Null} causes a run-time error. It is a compile-time error for a class to extend, mix in or implement \code{Null}.
 The \code{Null} class declares no methods except those also declared by \code{Object}.
 
 \LMHash{}
-The static type of \NULL{} is $\bot$.
+The static type of \NULL{} is the \code{Null} type.
 
-\rationale{The decision to use $\bot$ instead of \code{Null} allows \NULL{} to be be assigned everywhere without complaint by the static checker.
+\rationale{
+The \code{Null} type can be assigned anywhere without complaint by the static checker.

[karlklose, 2016/12/09 08:03:55]

Can you be more precise about what being assigned means for a type here?

[Lasse Reichstein Nielsen, 2016/12/09 10:32:44]

Hmm, not really. I think I'll just remove the entire rationale, since we don't
need to rationalize anything at this point of the spec any more, where
previously it gave a rationale for picking bottom as the static type of the null
literal.

 }
 
 
 \subsection{Numbers}
 \LMLabel{numbers}
 
 \LMHash{}
 A {\em numeric literal} is either a decimal or hexadecimal integer of arbitrary size, or a decimal double.
 
 \begin{grammar}
@@ skipping 4730 matching lines @@
 \item
 If $I$ is listed in the \EXTENDS{} clause of $J$% or an interface injection declaration has extended $J$ with $I$
 .
 \item If $I$ is listed in the \IMPLEMENTS{} clause of $J$
 
 \item If $I$ is listed in the \WITH{} clause of $J$
 
 \item If $J$ is a mixin application (\ref{mixinApplication}) of the mixin of $I$.
 \end{itemize}
 
-\commentary{
-
-
-}
-
 %\Q{Can wacky stuff happen with interface injection, e.g., a direct superinterface becomes indirect? What about side effects - loading order can affect type relationships.
 %}
 
 \LMHash{}
 A type $T$ is more specific than a type $S$, written $T << S$,  if one of the following conditions is met:
 \begin{itemize}
 \item $T$ is $S$.
 \item T is $\bot$.
+\item T id \NULL{} and $S$ is not $\bot$.

[karlklose, 2016/12/09 08:03:55]

'id' -> 'is'

[Lasse Reichstein Nielsen, 2016/12/09 10:32:44]

Done.

 \item S is \DYNAMIC{}.
 \item $S$ is a direct supertype of $T$.
 \item $T$ is a type parameter and $S$ is the upper bound of $T$.
 \item $T$ is a type parameter and $S$ is \cd{Object}.
 \item $T$ is of the form $I<T_1, \ldots, T_n>$ and $S$ is of the form $I<S_1, \ldots, S_n>$ and:
 $T_i << S_i, 1 \le i \le n$
 \item $T$ and $S$ are both function types, and $T << S$ under the rules of section \ref{functionTypes}.
 \item $T$ is a function type and $S$ is \cd{Function}.
 \item $T << U$ and $U << S$.
 \end{itemize}
 
 \LMHash{}
 $<<$ is a partial order on types.
 $T$ is a subtype of $S$, written $T <: S$, iff $[\bot/\DYNAMIC{}]T << S$.
 
 \rationale{
 Note that $<:$ is not a partial order on types, it is only binary relation on types. This is because $<:$ is not transitive. If it was, the subtype rule would have a cycle. For example:
 $List <: List<String>$ and $List<int> <: List$, but $List<int>$ is not a subtype of $List<String>$.
 Although $<:$ is not a partial order on types, it does contain a partial order, namely $<<$. This means that, barring raw types, intuition about classical subtype rules does apply.
 }
 
 \LMHash{}
 $S$ is a supertype of $T$, written $S :> T$, iff $T$ is a subtype of $S$.
 
 \commentary{The supertypes of an interface are its direct supertypes and their supertypes. }
 
 \LMHash{}
-An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$ or $S <: T$.
+An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$, $S <: T$, or either $T$ or $S$ is the \code{Null} type.
 
 \rationale{This rule may surprise readers accustomed to conventional typechecking. The intent of the $\Longleftrightarrow$ relation is not to ensure that an assignment is correct. Instead, it aims to only flag assignments that are almost certain to be erroneous, without precluding assignments that may work.
 
 For example, assigning a value of static type Object to a variable with static type String, while not guaranteed to be correct, might be fine if the runtime value happens to be a string.
 }
 
 \subsection{Function Types}
 \LMLabel{functionTypes}
 
 \LMHash{}
@@ skipping 587 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------