Bob Nystrom
Bob Nystrom
Working on augmentations [raises some questions](https://github.com/dart-lang/language/issues/3690) around which compile errors are defined on a single syntactic declaration or the resulting semantic declaration after all augmentations are merged. For most errors,...
Admin comment: this is moving to implementation. * [Feature specification](https://github.com/dart-lang/language/blob/main/accepted/future-releases/2509-private-named-parameters/feature-specification.md) * [Implementation issue](https://github.com/dart-lang/sdk/issues/61630) * Experiment flag: `private-named-parameters`. --- This is the tracking issue for the [Private Named Parameters][] proposal. [private...
The patterns proposal adds a new "if-case" statement form for matching a single refutable pattern: ```dart if (json case [int x, int y]) { print('Was coordinate array $x,$y'); } else...
The [null-aware elements proposal](https://github.com/dart-lang/language/blob/main/working/0323-null-aware-elements/feature-specification.md) deals with type inference and that type inference uses the surrounding context type. That implies that implicit coercions (casts from `dynamic`, implicit generic function instantiations, and...
This issue tracks the work needed to support ["Private Named Parameters"](https://github.com/dart-lang/language/blob/main/accepted/future-releases/2509-private-named-parameters/feature-specification.md) in Dartdoc. This feature does impact Dartdoc in that we want a private named parameter to be documented as...
### Page URL https://dart.dev/effective-dart/design#do-type-annotate-fields-and-top-level-variables-if-the-type-isnt-obvious ### Describe the problem The "DO type annotate fields and top-level variables if the type isn't obvious" rule encourages users to write explicit type annotations on...
This tracks updating our language documentation to talk about ["Private Named Parameters"](https://github.com/dart-lang/language/blob/main/accepted/future-releases/2509-private-named-parameters/feature-specification.md). TODO(rnystrom): Work with tech writers to figure out what we would like to write in docs. cc @antfitch