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

Szymon Gatner noemail at gmail.com
Fri Sep 20 07:13:12 PDT 2013


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?



More information about the Digitalmars-d mailing list