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

[Dmitry Olshansky]

20-Sep-2013 15:08, Nick Sabalausky пишет:
> On Fri, 20 Sep 2013 14:47:38 +0400
> Dmitry Olshansky <dmitry.olsh at 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