Skip to content

Specify interactions with older language versions #2538

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Oct 3, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions accepted/future-releases/records/records-feature-specification.md
Original file line number Diff line number Diff line change
Expand Up @@ -669,8 +669,56 @@ The runtime type of `pair` is `(int, double)`, not `(num, Object)`, However, the
variable declaration is still valid and sound because records are naturally
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`.

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`.

It is an error for the record type syntax (e.g. `(int, int)`) to be used
syntactically in a library whose language version is less than `v`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are specifically enumerating the differences (and not just implicitly saying that the older language versions use the language which was current at that point), we should also mention the disambiguation changes:

  • try { } catch { } on (e) {} has a method declaration named on in language < v, but doesn't in language >= v.
  • @Foo () Function() f; is a constructor invocation in the annotation in language < v, but isn't in language >= v.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be covered elsewhere (e.g. by the section that @munificent is adding on the grammar). This section describes the interactions between different language versions: it does not specify how the syntax of the the current language version is different from the syntax of the old language version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I can see the distinction.
Saying that

It is an error for the record type syntax (e.g. (int, int)) to be used
syntactically in a library whose language version is less than v.

does look like it's saying where the new syntax differs from the old syntax - this syntax is in the new language, and not in the old.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point of this section is to describe the interactions between language versions. It does so by circumscribing the set of errors that arise from using record features in older language versioned libraries (and noting that certain things are not in that set of errors, e.g. types that arise by inference). The first of the two things you mention is already covered in this proposal, I don't see value in adding it here. The second thing, I don't know the answer to, it's still under discussion.

If you really believe that these should be covered here, I'd suggest following up with a PR to re-organize as you prefer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. If this section is simply on records, and not the entire feature around them (and we don't even know if those two changes will be rolled into the records flag, or just be released independently), then it makes sense to focus only on the actual record types.

I was considering those two changes as part of the records feature, at an equal level to record syntax, but that's probably premature.

So keep as is.


*Note that the above errors only apply to direct syntactic uses of the new
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.*


## CHANGELOG

### 1.15

- Specify the interaction between libraries with a language version that
supports records and libraries with older language versions.

### 1.14

- Specify type inference, add static semantics to resources/type-system
Expand Down