On Friday, 20 September 2013 at 14:04:06 UTC, Dmitry Olshansky
wrote:
20-Sep-2013 17:50, Szymon Gatner пишет:
On Friday, 20 September 2013 at 13:32:47 UTC, Dmitry Olshansky
wrote:
20-Sep-2013 15:01, Szymon Gatner пишет:
On Friday, 20 September 2013 at 10:47:52 UTC, Dmitry
Olshansky wrote:
[snip]
A text-book example of self-destruction(?).
Ranges (in particular Input/Forward) are not much above
encapsulation
of iteration, hence must contain that state required to
iterate said
elements. Which leads to the point that indeed containers
have no
business being ranges by themselves.
The bottom line is:
sort(container[]);
vs
sort(container);
Where I hardly see how coupling containers with algorithms
can bring
even slightest benefit.
OK so it seems we agree. I never said that containers should
be ranges.
Ranges are abstraction on iterators and that is it. Single
container can
have multiple ranges existing at the same time. State is
attached to
ranges not containers. And most importantly ranges are mutable
always,
even if underlying container isn't. Ranges are meant to have
state. No
idea what you mean by self destruction.
Then it may be a misunderstanding on my part. I was referring
to your previous reply. Where I basically said:
>> Can't a container be a range as well?
>>
>For Christ sake no, no and no.
[... Because that would be ...]
> TL;DR: Suboptimal, unnatural and error prone are keywords.
Then your question - Why would it be suboptimal?
Which your second reply seem to clearly explain: extra state
placed where it doesn't belong. I can't easily correlate your
two answers as they look as if the second one answers questions
of the first.
Anyhow we are in agreement here.
Mind that "Can't a container be a range as well?" was not from
me. Still, moving computation over a range from for loop body
into the range implementation (like filtering) incurs no
performance penalty and has additional benefits of composability
and maintainability. Do you mean that is suboptimal?
