Dart Language Design and Specification

Enhanced part files generalize library files, part files, and augmentation files into a consistent system. This feature allows part files to declare their own imports, addressing the limitation where all imports previously had to be declared in the main library file. This is particularly useful for:

1. Large Libraries: Splitting tightly coupled classes into separate files while maintaining library privacy.
2. Partial Declarations: Splitting a single class or declaration across multiple files (similar to partial classes in C#).
3. Code Generation: Providing a structured way for augmentations and macros to add new code, imports, and exports to a library.

The 'Simpler Parameters' proposal aims to rationalize Dart's parameter syntax by making calling conventions and optionality orthogonal and consistent.

Key changes include:

• Calling Convention: Always specified by a delimited section (positional vs. named).
• Optionality: Specified on a per-parameter basis using a default value expression. This replaces the required keyword and the [...] section syntax.
• Expanded Support: Allows functions to have both optional positional and named parameters simultaneously.

Note: This is an old proposal from 2017 and has been superseded by a newer, active proposal. This document serves as a historical resource explaining the conceptual foundation for adding non-nullable types to Dart.

Key concepts from this proposal include:

• Non-nullable by default: Types are non-nullable unless specified otherwise.
• Nullable via ?: Appending ? to a type makes it nullable.
• Union Type Semantics: A nullable type (e.g., String?) is treated as a union of the base type and the Null class (String | Null).
• Safety: Nullable types do not support the methods of the base type (except those on Object), preventing NoSuchMethodError when a value is null.

Dart's pattern design distinguishes between two types of patterns based on the context in which they are used:

1. Matcher Patterns (Refutable): Used in contexts like switch cases. These patterns can fail to match (be 'refuted'). For example, a pattern might check if a value matches a specific constant.
2. Binder Patterns (Irrefutable): Used in contexts like variable declarations (e.g., var [x, y] = ...). These patterns are used to extract values and bind them to identifiers. They must be 'irrefutable', meaning they are guaranteed to succeed for the given structure.

This distinction allows the same syntax (like a bare identifier) to mean different things depending on the context: in a case, it acts as a matcher; in a variable declaration, it acts as a binder.

Type promotion allows you to avoid explicit casts when a variable's type is obvious from the surrounding code. For example, if you perform an is String check, Dart 're-types' the variable to String within the scope where that check is true.

Note: This specific proposal for 'Enhanced Type Promotion' is inactive and has been superseded by the more sophisticated flow analysis included with Dart's null safety. For current behavior, refer to the flow analysis documentation.

int stringLength(Object o) {
  if (o is String) {
    return o.length; // OK! The variable 'o' is promoted to String
  } else {
    throw "Not a string.";
  }
}

In a Bazel-based monolithic repository, the concept of a 'package' differs from a standard Dart pub package.

• A Bazel package is a directory containing a BUILD file. It includes all files in that directory and subdirectories, unless those subdirectories also contain a BUILD file.
• Mapping pub packages to Bazel:
  • package:<a>.<b>/uri.dart resolves to //a/b/lib/uri.dart.
  • package:<name>/uri.dart (where name has no dots) resolves to //third_party/dart/<name>.

Unlike pub packages where all files in lib/ are accessible via a dependency, Bazel uses targets within a package to provide granular access control.