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

[Szymon Gatner]

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?