On Friday, 27 July 2012 at 01:56:33 UTC, Stuart wrote:
On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
D uses ranges instead of iterators. You can read more about
them here: http://ddili.org/ders/d.en/ranges.html
I find ranges to be a vast improvement over iterators
personally (I use iterators extensively in C++ for my job and
lament not having ranges regularly).
On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
D has something far superior: ranges.
http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1
Even better, they are completely implemented in the library. No
unnecessary language bloat just to support them.
I'm not very well up on ranges. I understand the general [1 ...
6] type of ranges, but I really don't see how custom range
functions could be as useful as the Yield support in VB.NET.
Yes, I think H. S. Teoh wrote what that without knowing what
C#/VB iterators actually are.
.NET has a concept of "enumerators" which are basically
equivalent to D's "input ranges". Both enumerators and input
ranges are easier to use and safer than C++ iterators. Neither
enumerators nor input ranges require any language support to use,
but both C# and D have syntactic sugar for them in the form of
the foreach statement. Both C# and D input ranges can be infinite.
C#/VB "iterators", however, are an additional syntactic sugar
that transforms a function into a state machine that provides an
enumerator (or "enumerable"). These are indeed very useful, and
missing from D. Here is an example of an iterator that I updated
today:
public IEnumerable<IMapOverlay> Overlays() {
foreach (var ps in _patterns)
{
yield return ps.RouteLine;
yield return ps.PermShapes;
if (ps.Selected)
yield return ps.SelShapes;
}
}
It does not work like opApply; the compiler creates a heap object
that implements IEnumerable or IEnumerator (depending on the
return value that you ask for -- it is actually IEnumerator that
works like a forward ranges, but foreach only accepts
IEnumerable, which is a factory for IEnumerators)
In D you could use opApply to do roughly the same thing, but in
that case the caller cannot treat the opApply provider like an
ordinary collection (e.g. IIUC, the caller cannot use map or
filter on the results).
