649c4e6c85
.. and checked that they can occur also in Dart 2; added a comment about why this is so, on each of them. Also, got rid of the term "run-time error": the majority of references to errors at run time were "dynamic error", and now that is the term used everywhere. Cf. https://github.com/dart-lang/sdk/issues/34521. Change-Id: I7579c84a8d52199524770fb91c64804173ed533d Reviewed-on: https://dart-review.googlesource.com/c/90243 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com> |
||
|---|---|---|
| .. | ||
| assert-in-initializer-list.md | ||
| covariant-from-class.md | ||
| covariant-overrides.md | ||
| dynamic-members.md | ||
| extreme-upper-lower-bounds.md | ||
| generalized-void.md | ||
| generic-function-instantiation.md | ||
| generic-function-type-alias.md | ||
| generic-method-syntax.md | ||
| implicit-creation.md | ||
| instantiate-to-bound.md | ||
| int-to-double.md | ||
| int64.md | ||
| interface-conflicts.md | ||
| invalid_returns.md | ||
| mixin-declaration.md | ||
| mixin-inference.md | ||
| nosuchmethod-forwarding.md | ||
| optional-new-const.md | ||
| README.md | ||
| subtyping.md | ||
| super-bounded-types.md | ||
This directory contains feature specifications.
Note: This directory contains older feature specifications, new ones should be submitted to the language repository here.
The existing feature specifications in this directory will have their status updated as we proceed, and in particular each of them will become 'background' material as it is integrated into the language specification. When all feature specifications in this directory (that is, all other files than this one) have become background material, this directory will serve only as documentation for the process whereby each feature was designed and the associated motivation.
That said, the following section contains a few words about what a feature specification is, and how it can be used.
What is a Feature Specification?
In order to move faster and get better feedback, we implement and iterate on language changes before the full official specification has been written. Still, the implementers need something to go on.
For that, the language team writes feature specifications. These are intended to be precise enough for a good faith implementer to correctly understand the syntax and semantics of the language, but when the contents of a feature specification is integrated into the language specification we expect the extra processing to give rise to additional clarifications and corrections, which means that a feature specification is expected to be nearly as complete and correct as the language specification.