[change] `loadLibrary` should return `FutureOr`

[gmpassos]

Change Intent

The loadLibrary, used to ensure that a deferred library is load, should return a FutureOr for optimization purpose.

Justification

If loadLibrary returns a FutureOr will be possible to avoid waiting of a Future already resolved.

Here is a current workaround that avoids await to call a code that depends on a deferred library:

// The business part of the UI should be lazy loaded:
import 'ui_business.dart' deferred as ui_business;

bool _ui_business_loaded = false;

/// Perform a `call` that depends on `ui_business`.
FutureOr<R> ui_business_call<R>(R Function() call) {
  if (_ui_business_loaded) {
    return call();
  }

  return _ui_business_call_async<R>(call);
}

Future<R> _ui_business_call_async<R>(R Function() call) async {
  await ui_business.loadLibrary();
  _ui_business_loaded = true;
  return call();
}

With the proposed change:

// The business part of the UI should be lazy loaded:
import 'ui_business.dart' deferred as ui_business;


/// Perform a `call` that depends on `ui_business`.
FutureOr<R> ui_business_call<R>(R Function() call) {
  var load = ui_business.loadLibrary();
  if (load is Future) {
    return load.then((_) => call());
  } else {
    return call();
  }
}

Impact

Current Dart code won't be affected if using await.

Only a code using then will need to be changed.

Mitigation

FutureOr.then could also be provided by dart:async, improving usage of FutureOr.

If FutureOr.then is also provided, no change in current code will be needed.

Change Timeline

No deprecation is needed.

Associated CLs

None

[kevmoo]

SGTM! I'm not (too) worried about .then on Future in this context. Maybe in some old code.

[rakudrama]

@gmpassos Could you explain the practical impact of the optimization? await on a completed Future for the second time the await happens should be fast, even though it permits other code in the microtask queue to run. How much gain do you see from the optimization?

Implicit in this request is that loadLibrary() actually returns something other than a Future when the import has been successfully loaded.

[rakudrama]

Note that it is possible to generalize the work-around to one piece of code that works for all deferred imports.
The trick is to tear-off the loadLibrary method and use it as a key into a Set of loaded libraries.

import 'dart:async';

import 'dart:typed_data' deferred as typed_data;

typedef LoadFunction = Future<void> Function();

FutureOr<R> callWithLoadedLibrary<R>(LoadFunction loader, R Function() action) {
  print('callWithLoadedLibrary');
  if (_loaded.contains(loader)) return action();
  print('loading');
  return loader().then((_) {
    print('loaded');
    _loaded.add(loader);
    return action();
  });
}

final Set<LoadFunction> _loaded = {};

main() async {
  final r1 = await callWithLoadedLibrary(typed_data.loadLibrary, () {
    print('f1');
    return typed_data.Uint8List(3);
  });
  
  final f2 = callWithLoadedLibrary(typed_data.loadLibrary, () {
    print('f2');
    return typed_data.Uint8List(5);
  });

  if (f2 is Future) throw 'unexpected';
  print('done $r1 $f2');
}
}

prints:

callWithLoadedLibrary
loading
loaded
f1
callWithLoadedLibrary
f2
done [0, 0, 0] [0, 0, 0, 0, 0]

/cc @lrhn

[lrhn]

I'm generally opposed to giving FutureOr to people.

Either you don't know whether it's done, and therefore you need to have the async code path anyway, on top of the synchronous "optimized" part, or you do know that it's done, because someone checked already, but haven't cached it's result.

Having two interleaved code paths, one sync and one async, doing the same computation, is unlikely to be worth the code size increase. And complexity. And testing trouble, to make sure all the combinations are tested.

If it is worth it, it's because the code is running very often, and then it's better to have a single wait guarding access to everything, and all synchronous code behind that one wait. That's what the example code here does: Do an async operation once, then cache that it was done.

Using multiple functions returning FutureOr for code that is mostly synchronous, except the first time, is just not a design I want to encourage, or support.

[gmpassos]

First and foremost, thank you for the quick response and for participating in this discussion.

Here's a pratical example:

https://github.com/gmpassos/deferred_lib_issue

(The issue only happens when running from dart test: dart-lang/test#2088)

---

In this example, you can observe how to create a straightforward framework that accommodates the use of both Future and FutureOr, depending on the desired ViewBase implementation.

Just run the web/index.html through webdev:

webdev serve --launch-in-chrome -r

I believe the primary focus of our discussion should not solely revolve around performance but should also emphasize ease of use. I recommend attempting to write code that minimizes the excessive use of Future. This approach will help illustrate my perspective more clearly.

I make a conscious effort to minimize the usage of Future and await in the code,
as their introduction often necessitates the implementation of numerous other methods as async.

The consequence of having numerous async methods is unfavorable; it results in larger code size, complexities in stack traces, difficulties in debugging, increased memory allocation (as each Future generates a new object for the GC), and impedes compiler optimization.

When working with a deferred library that utilizes a non-asynchronous prefix, it introduces a dependency on prefix.loadLibrary(). This, in turn, introduces hidden asynchronous behavior for each exported element from the deferred library. Therefore, a deferred library is more akin to FutureOr (something that can be either asynchronous or synchronous) than to Future.

Creating an application that truly adheres to import compartmentalization can be challenging. However, using a deferred library with numerous exported elements can also be complex due to the hidden asynchronous flow inherent in the deferred pattern.

One thing I truly appreciate about Dart is that it doesn't impose a specific programming paradigm but rather provides you with the best tools for each use case. In the latest updates to the language, we've seen advancements in both Functional Programming and Object-Oriented capabilities. This is remarkable, especially considering that many languages tend to segregate paradigms rather than unify them.

However, when it comes to discussing Future and FutureOr, it seems like you're advocating for the widespread use of async methods. In my view, we should leverage the advantages of FutureOr whenever possible, without obscuring it.

---

I am the author of the async_extension package, which facilitates smoother interactions with FutureOr:
https://pub.dev/packages/async_extension