<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>The Model 3 document posits several migration compatibility
      goals.  I'd like to drill into these and get consensus on them, as
      they influence many other decisions (such as the requirements
      around raw types.)  Here's what the doc said:</tt><br>
    <h2 id="compatibility" style="font-size: large; margin-top: 3ex;
      margin-bottom: 0ex; color: rgb(0, 0, 0); font-family: 'Bitstream
      Vera Sans', Verdana, 'sans serif'; font-style: normal;
      font-variant: normal; letter-spacing: normal; line-height: normal;
      orphans: auto; text-align: start; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 1;
      word-spacing: 0px; -webkit-text-stroke-width: 0px;">Compatibility</h2>
    <p style="margin: 1ex 0em; color: rgb(0, 0, 0); font-family:
      'Bitstream Vera Sans', Verdana, 'sans serif'; font-size: medium;
      font-style: normal; font-variant: normal; font-weight: normal;
      letter-spacing: normal; line-height: normal; orphans: auto;
      text-align: start; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 1; word-spacing: 0px;
      -webkit-text-stroke-width: 0px;">Classes will evolve; some
      evolutions are compatible, and some are not. The following
      enumerates the compatibility consequences of the proposed
      approach.</p>
    <ul style="color: rgb(0, 0, 0); font-family: 'Bitstream Vera Sans',
      Verdana, 'sans serif'; font-size: medium; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: normal; orphans: auto; text-align: start;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
      <li style="margin: 0ex 0em; list-style-type: square;">Alpha-renaming
        a type variable (to a non-shadowed name) should be binary and
        source compatible.</li>
      <li style="margin: 0ex 0em; list-style-type: square;">Reordering
        or removing type variables is not compatible. (These first two
        together match the story for method argument lists; you can
        rename method arguments, but not reorder or remove them.)</li>
      <li style="margin: 0ex 0em; list-style-type: square;">Anyfying an
        existing erased type variable should be binary and source
        compatible.</li>
      <li style="margin: 0ex 0em; list-style-type: square;">Adding a new
        type variable<span class="Apple-converted-space"> </span><em>at
          the end</em><span class="Apple-converted-space"> </span>of the
        argument list should be binary compatible (though not source
        compatible.) Adding a new type variable other than at the end is
        not compatible.</li>
      <li style="margin: 0ex 0em; list-style-type: square;">Generifying
        an enclosing scope (evolving<span class="Apple-converted-space"> </span><code style="white-space: pre; font-family: 'courier new', monospace; font-size: medium; font-weight: bold;">Outer.Inner<U></code><span
          class="Apple-converted-space"> </span>to<code style="white-space: pre; font-family: 'courier new', monospace; font-size: medium; font-weight: bold;">Outer<T>.Inner<U></code>)
        should be binary compatible.</li>
      <li style="margin: 0ex 0em; list-style-type: square;">Changing
        type variable bounds is not binary compatible.</li>
    </ul>
    <tt><br>
      <br>
      Does anyone have any concerns with these compatibility goals (in
      either direction -- that they are too constraining, or not
      constraining enough?)  <br>
      <br>
      <br>
      <br>
    </tt>
  </body>
</html>