Bartosz Milewski seems to like D more than C++ now :)

[Nick Sabalausky]

On Fri, 20 Sep 2013 14:47:38 +0400
Dmitry Olshansky <dmitry.olsh at gmail.com> wrote:
> For Christ sake no, no and no. For starters range skips/drops
> elements when iterating, and thusly iteration has its own state that
> is useless for a container otherwise.
> 
> The idea of "contange" spreads like virus, no matter how abominable
> the end result is. The fact that slices sometimes look like
> containers (BTW ill-suited for anything beyond primitives/PODish
> stuff )  must be the corner stone of this belief. Strengthened on the
> motto of trying to make user defined types to mimic behavior of
> built-ins it leads to a school of thought that it's fine to blend
> ownership and access.

I can vouch that ease of conflating array/slice/range, while normally
a wonderful convenience, has indeed led me into confusion when trying to
make a custom type range-compatible.

I felt naturally inclined to add the range primitives to the type
itself, but when that led to issues like you described (especially the
fact that a range *consumes* its elements while iterating, plus the
inability to provide alternate views of the same data - which is a
very powerful tool IMO), I finally started to grok that a container
needs to *provide* a range, and not actually *be* one.

Well, except maybe for output ranges. (I think?)

> 
> TL;DR: Suboptimal, unnatural and error prone are keywords.
> 

They are? Cool!

auto foo(T)(real a, unnatural b, lazy Suboptimal!T opts) {...}

Looks fun! :)