Impressed

[David Piepgrass]

> I'd say this argument on which is "better", yield or ranges, is 
> a problem ill posed.

Yeah, since yielding is just a convenient way to implement an 
input range, asking which is better is like asking "Which is 
better, pick-up trucks or vehicles?"

> "yield" adds real, nontrivial value, and is not entirely 
> implementable as a library. Walter and I saw some uses of it in 
> C# at Lang.NEXT that were quite impressive.
>
> On the other hand yield's charter is limited when compared to 
> that of ranges. Yield goes with the very simple "go through 
> everything once" functionality, which is essentially input 
> ranges - only a tiny part of ranges can do.

> "yield" adds real, nontrivial value, and is not entirely 
> implementable as a library. Walter and I saw some uses of it in 
> C# at Lang.NEXT that were quite impressive.

Agreed. However, I have been looking at D's Fibers and I wonder 
if an optimized implementation of them could provide the same 
functionality reasonably well:

https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

The only problem is performance (and perhaps memory usage, but 
there are ways to reduce that). Someone reported that a trivial 
fiber-based forward range had 26x the overhead of opApply for 
iteration (70s vs 2.7s for 1 billion iterations). I wonder if the 
fiber-switching could be optimized? But I looked at core/thread.d 
and unless I'm missing something, the fiber switch does not 
appear to do much work: it calls Thread.getThis() twice per 
switch (= 4 times per iteration), getStackTop() (= rt_stackTop) 
once, and a naked asm routine with 21 asm instructions. The 
entire yield() process contains no branches; call() additionally 
calls setThis() twice and checks if the Fiber threw an exception. 
What's the easiest way to time something in D? I'm curious if 
Thread.getThis() (= TlsGetValue()) is the bottleneck.

Anyway, stack-switching lets you do not only the same things as 
C# 2's "yield return" but as far as I can tell, it can also do 
everything that C# 5's "async/await" can do and more:

http://qscribble.blogspot.ca/2012/07/asyncawait-vs-stack-switching.html

i.e. stack switching can accomplish tasks that async/await 
cannot, while I don't know of any cases of the reverse. async is 
more limited because all functions involved in an async task must 
be explicitly marked and transformed by the compiler, but stack 
switching works no matter what code is involved; even C code can 
be called on an asynchronous fiber task.