Dart Proposals Conditional Parts and `concrete` to End Cross-Platform Implementation Boilerplate
Flutter plugin and FFI developers currently juggle separate libraries, abstract classes, factories, and proxy layers to support multiple platforms; this proposal collapses that into a single class with platform `augment`s, and the analyzer guarantees no platform silently diverges from the agreed API.
Dart's language team has opened a draft PR (#4827) for conditional parts and a `concrete` modifier. Conditional parts let a `part` directive choose different implementation files based on the compilation target, just like conditional imports do today. The `concrete` keyword tells the analyzer that an abstract-looking method will actually have a body supplied by a platform-specific `augment`, so subclasses can call `super.close()` without error.
The proposal addresses a real pain point in Flutter plugins and FFI wrappers. With conditional imports, each platform implementation lives in a separate library, so private state like `_name` can't be shared, and nothing enforces API consistency across those files. Conditional parts keep everything in one library: `channel_io.dart` remains `part of 'channel.dart'`, can access private fields, and uses `augment` to fill in the method body. Each platform part can also import its own dependencies, like `dart:io`.
To keep static analysis deterministic, the proposal forbids conditional parts from adding new top-level declarations, new class members, `extends`/`implements`/`with` clauses, enum values, or changing parameter defaults. The analyzer checks the common public structure first, then validates that each platform's `augment` provides the required implementations. The author expects this to cut out abstract classes, factories, and proxy code for Flutter native/Web plugins, and to make FFI and JS interop wrappers far simpler.
The restriction table makes the trade-off explicit: platforms get to swap implementations but cannot extend the public shape of a class, which is exactly what enables the analyzer to check API consistency before platform selection happens.
The proposal mirrors Kotlin's expect/actual but avoids splitting the class declaration; instead of two separate declarations, Dart's `augment` modifies the same class, which keeps private state and type relationships in one place.
A `concrete` modifier is a clever reserve: it lets the analyzer infer existence of a method body without ever reading the conditional file, so subclasses can legally call `super` without a compile-time error on the common declaration.
The two remarks question whether Dart's new proposal arrives too late to matter. One notes Flutter's overall development has fallen behind expectations, and the other doubts that a feature this long in the making will inspire much adoption momentum. Both share a pessimistic outlook on timing and community eagerness.
To be honest, Flutter's progress is much slower than expected.
It's taken this many years to only now do this; the enthusiasm to follow up probably won't be strong, will it?