Unnamed libraries do not cause warnings. Also minor correction wrt privacy.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
 (4th edition draft)\\
@@ skipping 2029 matching lines @@
 \LMHash{}
 A  mixin application of the form  \code{$S$ \WITH{} $M$;} defines a class  $C$ with superclass  $S$. 
 
 \LMHash{}
 A  mixin application of the form  \code{$S$ \WITH{} $M_1, \ldots, M_k$;} defines a class  $C$ whose superclass is the application of the mixin composition (\ref{mixinComposition}) $M_{k-1} * \ldots * M_1$ to $S$. 
 
 \LMHash{}
 In both cases above, $C$ declares the same instance members as $M$ (respectively, $M_k$). If any of the instance fields of $M$ (respectively, $M_k$) have initializers, they are executed in the scope of $M$ (respectively, $M_k$) to initialize the corresponding fields of $C$. 
 
 \LMHash{}
-For each generative constructor named $q_i(T_{i1}$ $ a_{i1}, \ldots , T_{ik_i}$ $ a_{ik_i}), i \in 1..n$ of $S$, $C$ has an implicitly declared constructor named
+Let $L_M$ be the library in which $M$ is declared.
+For each generative constructor named $q_i(T_{i1}$ $ a_{i1}, \ldots , T_{ik_i}$ $ a_{ik_i}), i \in 1..n$ of $S$ that is accessible to $L_M$, $C$ has an implicitly declared constructor named
 $q'_i = [C/S]q_i$ of the form 
 
 $q'_i(a_{i1}, \ldots , a_{ik_i}):\SUPER(a_{i1}, \ldots , a_{ik_i});$.
 
 %super.id
 
 \LMHash{}
 If the mixin application declares support for interfaces, the resulting class implements those interfaces.
 
 \LMHash{}
@@ skipping 4720 matching lines @@
 The policy above makes libraries more robust in the face of additions made to their imports.  
 
 A clear distinction needs to be made between this approach, and seemingly similar policies with respect to classes or interfaces.  The use of a class or interface, and of its members, is separate from its declaration. The usage and declaration may occur in widely separated places in the code, and may in fact be authored by different people or organizations.  It is important that errors are given at the offending declaration so that the party that receives the error can respond to it a meaningful way.
 
 In contrast a library comprises both imports and their usage; the library is under the control of a single party and so any problem stemming from the import can be resolved even if it is reported at the use site.
 
 %On a related note, the provenance of the conflicting elements is not considered. An  element that is imported via distinct paths may conflict with itself. This avoids variants of the well known "diamond" problem.
 }
 
 \LMHash{}
-It is a static warning to import two different libraries with the same name.
+It is a static warning to import two different libraries with the same name unless their name is the empty string.

[Brian Wilkerson, 2015/08/19 17:51:00]

Do we want similar wording for the export-related warning (on line 6883)?

 
 \commentary{
 A widely disseminated library should be given a name that will not conflict with other such libraries. The preferred mechanism for this is using pub, the Dart package manager, which provides a global namespace for libraries, and conventions that leverage that namespace.
 }
 
 \commentary{Note that no errors or warnings are given if one hides or shows a name that is not in a namespace.}
 \rationale{  
 This prevents situations where removing a name from a library would cause breakage of a client library.
 }
 
@@ skipping 243 matching lines @@
  Any use of a malformed  type gives rise to a static warning. A malformed type is then interpreted as \DYNAMIC{} by the static type checker and the runtime unless explicitly specified otherwise.
   
  \rationale{
 This ensures that the developer is spared a series of cascading warnings as the malformed type interacts with other types.
 }
 
 \LMHash{}
 A type $T$ is {\em deferred} iff it is of the form $p.T$ where $p$ is a deferred prefix.
 It is a static warning to use a deferred type in a type annotation, type test, type cast or as a type parameter. However, all other static warnings must be issued under the assumption that all deferred libraries have successfully been loaded.
 
+% Now, when passed to a generic, p.T also has to be treated as dynamic - otherwise we have to fail immediately. Where do we say that? And how does this fit with idea that as a type object it fails? Should we say that the accessor on p returns dynamic instead of failing? Do we distinguish its use in a constructor vs its use in an annotation? It's not that we evaluate type objects in constructor args - these cannot represent parameterized types.
+
 
 \subsubsection{Type Promotion}   
 \LMLabel{typePromotion}
 
 \LMHash{}
 The static type system ascribes a static type to every expression.  In some cases, the types of local variables and formal parameters may be promoted from their declared types based on control flow. 
 
 \LMHash{}
 We say that a variable $v$ is known to have type $T$ whenever we allow the type of $v$ to be promoted. The exact circumstances when type promotion is allowed are given in the relevant sections of the specification (\ref{logicalBooleanExpressions}, \ref{conditional} and \ref{if}).
 
@@ skipping 799 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.
 
 ----------------------------------------------------------------------