Assignability, generics

Author: eernstg

specification/dart.sty

@@ -357,12 +357,6 @@
 \newcommand{\Supertype}[3]{\ensuremath{{#1}\vdash{#2}\,:>\,{#3}}}
 \newcommand{\SupertypeStd}[2]{\Supertype{\Gamma}{#1}{#2}}
 
-% Judgment expressing that an assignability relation exists.
-\newcommand{\AssignableRelationSymbol}{\ensuremath{\Longleftrightarrow}}
-\newcommand{\Assignable}[3]{%
-  \ensuremath{{#1}\vdash{#2}\,\AssignableRelationSymbol\,{#3}}}
-\newcommand{\AssignableStd}[2]{\Assignable{\Gamma}{#1}{#2}}
-
 % Semantic function delivering the superinterfaces of a class.
 \newcommand{\Superinterfaces}[1]{\ensuremath{\metavar{Superinterfaces}({#1})}}
 \newcommand{\Superinterface}[2]{{#1}\in\Superinterfaces{#2}}

specification/dartLangSpec.tex

@@ -7197,7 +7197,7 @@ \section{Generics}
 \LMHash{}%
 A type parameter $T$ may be suffixed with an \EXTENDS{} clause
 that specifies the \Index{upper bound} for $T$.
-If no \EXTENDS{} clause is present, the upper bound is \code{Object}.
+If no \EXTENDS{} clause is present, the upper bound is \code{Object?}.
 It is a
 \Error{compile-time error} if a type parameter is a supertype of its upper bound
 when that upper bound is itself a type variable.
@@ -22014,27 +22014,19 @@ \subsubsection{Additional Subtyping Concepts}
 \LMHash{}%
 A type $T$
 \Index{may be assigned}
-to a type $S$ in an environment $\Gamma$,
-written \AssignableStd{S}{T},
-if{}f either \SubtypeStd{S}{T} or \SubtypeStd{T}{S}.
-In this case we say that the types $S$ and $T$ are
-\Index{assignable}.
+to a type $S$ in an environment $\Gamma$
+if{}f $T$ is \DYNAMIC, or \SubtypeStd{T}{S}.
+In this case we also say that the type $T$ is \Index{assignable} to $S$.
 
 \rationale{%
-This rule may surprise readers accustomed to conventional typechecking.
-The intent of the \AssignableRelationSymbol{} relation
-is not to ensure that an assignment is guaranteed to succeed dynamically.
-Instead, it aims to only flag assignments
-that are almost certain to be erroneous,
-without precluding assignments that may work.
-
-For example, assigning an object of static type \code{Object}
-to a variable with static type \code{String},
-while not guaranteed to be correct,
-might be fine if the run-time value happens to be a string.
-
-A static analyzer or compiler
-may support more strict static checks as an option.%
+The use of the type \DYNAMIC{} is intended to shift type checks from
+compile time to run time,
+thus allowing operations that are not statically safe,
+but which may succeed or fail at run time.
+This treatment of \DYNAMIC{} ensures that
+expressions of type \DYNAMIC{} are treated
+as if the compiler would implicitly insert a downcast whenever needed,
+in order to make the program type correct.%
 }
 
 
@@ -23968,32 +23960,10 @@ \subsubsection{Const type variable elimination}
 \}
 \end{dartCode}
 
-\subsubsection{Extension method resolution}
+\subsubsection{Combined member signatures}
 
 !!!TODO!!!
 
-For the purposes of extension method resolution, there is no special treatment
-of nullable types with respect to what members are considered accessible.  That
-is, the only members of a nullable type that are considered accessible
-(and hence which take precedence over extensions) are the members on \code{Object}.
-
-For the purposes of extension method resolution, the type \code{Never} is considered
-to implement all members, and hence no extension may apply to an expression of
-type \code{Never}.
-
-\subsubsection{Assignability}
-
-The definition of assignability is changed as follows.
-
-A type $T$ is \Index{assignable} to a type $S$ if $T$ is \DYNAMIC, or if $T$ is a
-subtype of $S$.
-
-\subsubsection{Generics}
-
-The default bound of generic type parameters is treated as \code{Object?}.
-
-\subsubsection{Combined member signatures}
-
 This section, line 4241
 in the language specification defines the notion of a _combined member
 signature_. In Dart before null-safety it is based on the textually first