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

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 8232a3b4554b93cacaa92e9b401d0c7e8bc3ae9d..f74f8c02f8c465ad7037bc9ecc41010710a25440 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -2616,9 +2616,10 @@ The null object is the sole instance of the built-in class \code{Null}. Attempti
 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.

 }
 
 
@@ -7369,11 +7370,6 @@ If $I$ is listed in the \EXTENDS{} clause of $J$% or an interface injection decl
 \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.
 %}
 
@@ -7382,6 +7378,7 @@ A type $T$ is more specific than a type $S$, written $T << S$,  if one of the fo
 \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$.
@@ -7409,7 +7406,7 @@ $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.