[SideburnsOfDoom]

Is async streams and "await foreach" just syntactic sugar for things that could still be done beforehand, albeit with more code?

I mean, "slightly more code" - you can say the same about "async ... await" in general, but then it's "insanely more code" and huge potential for error.

It looks that way to me.

[akra]

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.

[merb]

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.

[SideburnsOfDoom]

>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.