Dart VM ↔ Flutter: Is null safety enforced when passing data into widget build methods?

Question

Dart VM ↔ Flutter: Null‑Safety Interop
When a null‑unsafe Dart library is imported into a null‑safe Flutter application, the compiler issues a warning but does not prevent the library’s methods from being called at runtime. The Flutter framework’s Widget.build method is invoked via dynamic dispatch, which may bypass the Dart VM’s static type checks. The goal is to determine whether null safety is preserved across this integration boundary.
Key constraints include the presence of a null‑unsafe library, a null‑safe Flutter widget tree, and the dynamic nature of widget build calls. Uncertainty remains about whether the VM’s runtime type checks are sufficient to catch null dereferences originating from the library when they reach widget build methods.
Questions for investigation:

Does the Dart VM perform type checks on method calls that originate in null‑unsafe libraries and are invoked within Flutter’s widget build?
If not, would a runtime guard be necessary to coerce null‑unsafe values into nullable types across the Dart VM ↔ Flutter boundary?
What verification steps can confirm that null safety is maintained throughout the integration?

Tasadduq Burney · Answer

Short answer
Yes. When null-safe Flutter code receives a value from a null-unsafe library, the Dart VM enforces null safety at the boundary. If that value is null and the receiving variable or parameter is non-nullable, the VM throws a TypeError at the crossing point. Flutter’s dynamic dispatch of Widget.build does not bypass these checks.

Confirmed behavior

Sound null safety (Dart 2.12+) inserts implicit runtime checks where legacy types flow into null-safe code.
Widget.build is an ordinary instance method; the framework invokes it through normal element rebinding, not through a mechanism that disables the type system.
Null-unsafe libraries are treated as legacy: their types are implicitly nullable, but static analysis does not flag null returns. The runtime check happens when the value is assigned to a non-nullable location.
No manual coercion or wrapper guard is required by default.

Assumptions
This assumes the Flutter app uses Dart 2.12 or later with sound null safety enabled, and Flutter 2.0 or later (null-safe framework). If the legacy library and the app are both compiled with a pre-2.12 language version, null safety is not enforced at all.

Verification steps

Run dart analyze in the Flutter app. Legacy interop usually produces no static errors because legacy types are treated as nullable.
In a widget constructor or build, pass a legacy-library return value into a non-nullable parameter, for example Text(legacyApi.title) where title is a legacy String.
Run the app in debug mode and exercise that code path. If the legacy function returns null, expect a TypeError at the assignment or call site, not silent propagation into the widget tree.
Optionally add a unit test that stubs the legacy function to return null and asserts the widget construction throws.

Missing diagnostic detail
Is the null-unsafe library constrained to a pre-2.12 SDK in its pubspec.yaml (environment: sdk: '<3.0.0' without a lower null-safe bound)? If both sides target pre-null-safety Dart, the boundary checks described above do not apply, and the recommendation changes to migrating the library or adding manual null checks.

Dart VM ↔ Flutter: Is null safety enforced when passing data into widget build methods?

Dart VM ↔ Flutter: Null‑Safety Interop

1 answer

Short answer

Confirmed behavior

Assumptions

Verification steps

Missing diagnostic detail

Your perspective belongs here.

0 question comments