004f564f40
A quirk of analyzer and CFE implementations is that they resolve property gets such as `foo.bar` to specific field or getter declarations that may be not be directly defined on the target type; for example if `foo` has type `B`, and `B` extends `A`, and `A` contains a field called `bar`, then `foo.bar` is considered to refer to `A.bar`, for example: class A { int? bar; } class B extends A {} f(B foo) { print(foo.bar); // Resolved to `A.bar`. } This is in contrast with the language specification, which makes a clean distinction between class _declarations_ and the _interfaces_ implied by those declarations. While a class declaration can contain (among other things) both getters and fields, which might be concrete or abstract, an interface doesn't distinguish between getters and fields, and is inherently abstract. The advantage of the analyzer/CFE approach is that it allows more intuitive error messages and "go to definition" behavior, which benefits users. But it has some ill-defined corner cases involving complex class hierarchies, because not every property access can be resolved to a unique declaration (sometimes a getter is multiply inherited from multiple interfaces, for example). The language spec approach has the advantage of being well-defined and consistent even in situations involving complex class hierarchies. When I initially implemented field promotion, I took advantage of this quirk of the analyzer and CFE implementations, so that I could make property gets that refer to field declarations promotable, while keeping property gets that refer to abstract getter declarations non-promotable. This caused unpredictable behaviors in the ill-defined corner cases. It also meant that in certain rare cases, a property access might not be promoted even when it would be sound to do so (e.g. a property access might refer to a private abstract getter declaration, but the only concrete _implementation_ of that abstract getter was a final field). This CL changes the rule for promotability so that any get of a private property is considered promotable, provided that the containing library doesn't contain any concrete getters, non-final fields, or external fields with the same name. It no longer matters whether the private property refers to a field or a getter. This rule is simpler than the old rule, restores the spec's clean distinction between class declarations and interfaces, and allows more promotions without sacrificing soundness. For additional details please see the breaking change announcement at https://github.com/dart-lang/sdk/issues/54056, as well as the original change proposal at https://github.com/dart-lang/language/issues/3328. Fixes https://github.com/dart-lang/sdk/issues/54056. Fixes https://github.com/dart-lang/language/issues/3328. Change-Id: I38ffcb9ecce8bccb93b1b2586a1222a0fb1005a7 Bug: https://github.com/dart-lang/sdk/issues/54056 Bug: https://github.com/dart-lang/language/issues/3328 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337609 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Lasse Nielsen <lrn@google.com> Commit-Queue: Paul Berry <paulberry@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com> |
||
---|---|---|
.dart_tool | ||
.github | ||
benchmarks | ||
build | ||
docs | ||
pkg | ||
runtime | ||
samples | ||
sdk | ||
tests | ||
third_party | ||
tools | ||
utils | ||
.clang-format | ||
.gitattributes | ||
.gitconfig | ||
.gitignore | ||
.gn | ||
.mailmap | ||
.style.yapf | ||
.vpython | ||
AUTHORS | ||
BUILD.gn | ||
CHANGELOG.md | ||
codereview.settings | ||
CONTRIBUTING.md | ||
DEPS | ||
LICENSE | ||
OWNERS | ||
PATENT_GRANT | ||
PRESUBMIT.py | ||
README.dart-sdk | ||
README.md | ||
sdk.code-workspace | ||
sdk_args.gni | ||
SECURITY.md | ||
WATCHLISTS |
Dart
A client-optimized language for fast apps on any platform
Dart is:
-
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
-
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
-
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
-
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
-
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
License & patents
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Using Dart
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
Building Dart
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
Contributing to Dart
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.