Allow "Record" to be seen from legacy libraries.

Fix #2661.

(Also apply tweak the formatting of some code and prose.)

Author: munificent

accepted/future-releases/records/records-feature-specification.md

@@ -512,31 +512,35 @@ If `K` is any other type schema:
 As noted above, contrary to the practice for runtime checked covariant nominal
 types, we do not prefer the context type over the more precise upwards type.
 The following example illustrates this:
+
 ```dart
-  // No static error.
-  // Inferred type of the record is (int, double)
-  (num, num) r = (3, 3.5)..$0.isEven;
+// No static error.
+// Inferred type of the record is (int, double)
+(num, num) r = (3, 3.5)..$0.isEven;
 ```
 
 Also note that implicit casts and other coercions are considered to be applied
 as part of inference, hence:
+
 ```dart
-  class Callable {
-    void call(num x) {}
-  }
-  T id<T>(T x) => x;
-  // No static error.
-  // Inferred type of the record is:
-  //    (int, double, int Function(int), void Function(num))
-  var c = Callable();
-  dynamic d = 3;
-  (num, double, int Function(int), void Function(num)) r = (d, 3, id, c);
+class Callable {
+  void call(num x) {}
+}
+T id<T>(T x) => x;
+// No static error.
+// Inferred type of the record is:
+//    (int, double, int Function(int), void Function(num))
+var c = Callable();
+dynamic d = 3;
+(num, double, int Function(int), void Function(num)) r = (d, 3, id, c);
 ```
+
 and the record initialization in the last line above is implicitly coerced to be
 the equivalent of:
+
 ```dart
-  (num, double, int Function(int), void Function(num)) r =
-     (d as num, 3.0, id<int>, c.call);
+(num, double, int Function(int), void Function(num)) r =
+   (d as num, 3.0, id<int>, c.call);
 ```
 
 See issue [2488](https://github.com/dart-lang/language/issues/2488) for some of
@@ -785,15 +789,11 @@ covariant in their field types.
 
 ### Interactions with libraries using older language versions
 
-The records feature is language versioned, as usual with new Dart features.
-This means that it will be an error to use the syntax for records in libraries
-which do not have a language version greater than or equal to the language
-version in which records are released.  More specifically, assuming that `v` is
-the language version in which records are released, the following errors apply.
-
-It is an error for the identifier `Record`, denoting the `Record` class from
-`dart:core`, where that import scope name is only imported from platform
-libraries, to appear in a library whose language version is less than `v`.
+The records feature is language versioned, as usual with new Dart features. This
+means that it will be an error to use the syntax for records in libraries which
+do not have a language version greater than or equal to the language version in
+which records are released. More specifically, assuming that `v` is the language
+version in which records are released, the following errors apply.
 
 It is an error for the record literal syntax (e.g. `(3, 4)`) to be used
 syntactically in a library whose language version is less than `v`.
@@ -806,28 +806,33 @@ record syntax in legacy libraries.  It is not an error for a library whose
 language version is less than `v` (a "legacy library") to include types which
 denote or include the `Record` class, record types or record expressions when
 these terms arise directly or indirectly from references to another library
-whose language version is greater than or equal to `v`.  For example, such a
-legacy library may reference a typedef name which is bound to a record type in
-another library, and the semantic interpretation of the typedef is as the
-underlying record type, just as it would be for any other type.  Similarly, type
-inference may introduce record types into a legacy library, and such types will
-be interpreted by the compiler as record types as usual (that is, there is no
-erasure implied to remove these inferred types).  A legacy library may refer to
-the `Record` class via a library which has re-exported it.  Record values may
-flow into a legacy library via a reference to a member from another library, and
-a legacy library may freely call getters on record values (since there is no new
-syntax for calling a record getter).  The rationale for the choices described in
-this section is that the intent of language versioning (for an additive feature
-such as records) is to ensure that users do not accidentally use new features in
-a package without specifying an SDK constraint which ensures that their code
-will always be run on an SDK which supports the feature.  But in the case of a
-legacy library which references record values or types indirectly via another
-library, the SDK constraint on the referenced library is sufficient to enforce
-this.*
-
+whose language version is greater than or equal to `v`.*
+
+*For example, such a legacy library may reference a typedef name which is bound
+to a record type in another library, and the semantic interpretation of the
+typedef is as the underlying record type, just as it would be for any other
+type. Similarly, type inference may introduce record types into a legacy
+library, and such types will be interpreted by the compiler as record types as
+usual (that is, there is no erasure implied to remove these inferred types).*
+
+*Record values may flow into a legacy library via a reference to a member from
+another library, and a legacy library may freely call getters on record values
+(since there is no new syntax for calling a record getter). The rationale for
+the choices described in this section is that the intent of language versioning
+(for an additive feature such as records) is to ensure that users do not
+accidentally use new features in a package without specifying an SDK constraint
+which ensures that their code will always be run on an SDK which supports the
+feature. But in the case of a legacy library which references record values or
+types indirectly via another library, the SDK constraint on the referenced
+library is sufficient to enforce this.*
 
 ## CHANGELOG
 
+### 1.19
+
+- Allow legacy libraries that don't support records to still be able to see the
+  `Record` class in "dart:core" (#2661).
+
 ### 1.18
 
 - Unconditionally treat `on` after a `try` block as an on clause even when not