On Fri, 20 Sep 2013 14:47:38 +0400 Dmitry Olshansky <dmitry.o...@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! :)