Summary

Dart Native Extensions is a mechanism for loading native code into a running Dart program and binding Dart methods to native implementatations.

It consists of the following parts:

• dart-ext:... import scheme which instructs VM to load a native library;
• native keyword which specifies that a function has a native implementation;
• Dart VM C API (as defined in runtime/include/dart_api.h) which can be used to reflectively inspect and mutate the state of the Dart program;

Currently native extensions only really work in a standalone Dart VM - Flutter embedder hides VM C API symbols and does not allow developers to interact with Dart through Dart VM APIs.

Relience on C API means that:

• Native extensions are not very efficient for fine-grained binding.
• Reflective access through Dart VM C API is also incompatible with AOT (requires careful usage of @pragma('vm:entry-point') which in turn disables treeshaking).

dart:ffi was designed to not have these problems - be both more effecient and more AOT friendly. dart:ffi works in standalone VM as well as Flutter.

From our perspective it does not make sense to maintain two completely different approaches to binding Dart code to native especially given that one of them is obviously superior. We don't want more packages using native extensions to appear in the ecosystem and we want to push all new Dart users to use dart:ffi.

We propose the following:

• In Dart 2.14 issue a deprecatin warning whenever analyzer or CFE see dart-ext: import.
• In Dart 2.15 remove support for dart-ext: imports and hide Dart VM C API symbols from standalone dart binary shipped with SDK

Impact

All packages that use dart-ext: will be broken by the release. We will work to estimate the impact, but we consider it to be very small because none of the Flutter compatible packages will be affected, as Flutter does not support this mechanism in the first place.

TODO

• end support for dart-ext import scheme in the analyzer #47407