dart:async should be part of dart core

[trinarytree]

The async keywords - async, await, yield, etc -
are available whether you import 'dart:async' or not, and can even produce async
objects like Futures and Streams:

// Obviously a Stream, but I'm not allowed to declare its type as such.
var geeWhatsThis = () async* {} ();

so it's a bit silly that dart:async isn't part of dart core.
I.e. you shouldn't have to explicitly import 'dart:async'.

[zoechi]

AFAIK the decision if something is in core or not, is not about whether it would be nice, but instead just whether it is absolutely necessary. The same for dart:xxx imports.
In Dart everything that can live in a package is moved to a package to keep the core as small as possible.

[floitschG]

We have discussed this issue before, and even on the Dart team we have different opinions on it.
Personally, I'm against adding async-types to the dart:core library, but others would very much like to expose Future and Stream in dart:core.

[trinarytree]

If we define "absolutely necessary" as "you can't run any Dart program without it",
then no type is "absolutely necessary" since you could just use var everywhere.
You can also create lists with [] and maps with {}.
But wouldn't it be a shame if you created a list with [] and couldn't properly declare its type
without importing something?

That's similar to my reasoning here. You can create Futures and Streams without importing
dart:async, so clearly that code is loaded anyway. Why make me jump through an extra
hoop just so I can declare the types of the resulting objects?

At the very least, dart:core ought to supply the types of all the things you can create with
the literal syntax:

• bool - because you can write true
• int - because you can write 1
• String - because you can write 'foo'
• Function - because you can write () {}
• List - because you can write []
• ...
• Future - because you can write () async {}()
• Stream - because you can write () async* {}()

That would make the core language self-contained.

[matanlurey]

This has become a paint point in early Dart 2.0 - it's bad practice to write () async { ... }, but you can't even express the language primitives without importing another library. So I'm a huge 👍 to adding Future and Stream to dart:core.

[kwalrath]

What's the status of this?

[srawlins]

+1 to @floitschG 's suggestion; export Future and Stream from dart:core. I don't think this should be considered a breaking change if it lands after Dart 2.0.

[natebosch]

There is always a risk of package authors failing to update their pubspec SDK constraint when they start using a new feature. This feature in particular is going to be very easy to accidentally start relying on without realizing it and not noticing that the pubspec needs to be changed. Downstream consumers will be broken by resolving to packages they shouldn't - flutter users especially fall victim to this.

We probably want either an analyzer hint or a pub validator to check this before packages are published. We'll want the analyzer or pub change to go out in the same SDK as this one. Should we consider rolling back for now until we can figure out a suitable safety net?

[natebosch]

Reclosing since the request for new checks is tracked in #34978 and dart-lang/pub#1981