Not quite. F# and a few other languages have had this capability for a few years now. Its effectively making the MoveNext() function on the enumerator object an async operation instead of a blocking one. This allows a foreach loop for example to wait until the next object comes without tying up the thread. Useful for things like pulling off a remote message queue, messages off a network, etc where the waiting for the next item in your "foreach" loop involves async/task based operations and you don't want to block the current thread.

nope async streams weren't really possible before without an unnecessary allocation.

i.e. a List<Task<T>> is not the same as an AsyncEnumerable<T>. List<Func<Task<T>>> would be more equivalent, but you needed to have a List<T> which you need to fill beforehand.

>nope async streams weren't really possible before without an unnecessary allocation.

You would have to define a few custom types. I have written code that looks something like

  while (! ctx.IsCancellationRequested)
  {
    var data = await source.GetData();  
    await Process(data);  
  }

Where source is an interface that we have defined. This is not much more complex than an async enumerable.

It's definitely possible, and if you save an allocation then that's a step up, but not a game changer for most business process.