20-Sep-2013 15:08, Nick Sabalausky пишет:
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),
Aye.
I finally started to grok that a container
needs to *provide* a range, and not actually *be* one.
This ^^
I can't stress that last statement enough.
Well, except maybe for output ranges. (I think?)
Output ranges in my mind may wrap a suitable container by ref.
I think that adding 'put' to container is not a bad idea.
It would essentially do insertAny(..) implying that order of insertion
is not interesting.
However since there are many ways of inserting items
(insertFront/insertBack?) it makes more sense in general
to have simple helper sink. backInserter ? Silly but simple to remember.
TL;DR: Suboptimal, unnatural and error prone are keywords.
They are? Cool!
Yes :)
1. Suboptimal - extra state to worry about, with mutation backed-in.
Harder path to immutability/shared.
2. Unnatural - the reason to have ranges in the first place? Now we pass
containers to algorithms ... The decoupling is lost.
3. Error prone - unclean semantics. Does iterating a container mutate
it? If not what about iterating it twice in a loop (inner-outer)? Is
there a copy somewhere? Copy of what? I can go on for days here.
auto foo(T)(real a, unnatural b, lazy Suboptimal!T opts) {...}
Looks fun! :)
--
Dmitry Olshansky
