Return type of generate method in Generator could be FutureOr

[tejainece]

Return type of generate method in Generator could be FutureOr. In my experience, it is usually synchronous.

https://github.com/dart-lang/source_gen/blob/master/lib/src/generator.dart#L23

[jakemac53]

Sounds reasonable to me, the only supported file apis (buildStep.readAs{String|Bytes}) are async so that is why it was async before FutureOr was a thing. Now that it exists though I agree it is a better option.

[lrhn]

I generally discourage using FutureOr as a return type for user-callable functions in an API.
It means that the user must check the return value for being a future, and be prepared to handle both cases. In that case, it's actually easier for the user to always return a future.

The place to use FutureOr is where the user can supply your code with either a future or a value (or a function returning either of the two), because that allows the user to use a value directly without having to wrap it as a future. That is, if your API mentions FutureOr, it should be because you are ready to handle the complexity, not because the user of the API must handle it.

(I don't know the source_gen package well enough to see which case this is, so it might be perfectly fine usage here).

[natebosch]

This is a case where the user is supplying us with the method returning FutureOr and we are handling it. We end up using await so we hit the microtask queue regardless, but this change is mainly so that the cases which could be synchronous don't need to add an async just to return a Future.

[matanlurey]

In this case, the return value of Generator is not really a user API as much as a framework one. The build/source_gen framework will check to see if the user is providing a synchronous or asynchronous API.

[lrhn]

Super, keep it up :)