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

[Dmitry Olshansky]

20-Sep-2013 18:48, H. S. Teoh пишет:
> On Fri, Sep 20, 2013 at 05:36:59PM +0400, Dmitry Olshansky wrote:
>> 20-Sep-2013 14:55, Szymon Gatner пишет:
>>> On Friday, 20 September 2013 at 10:47:52 UTC, Dmitry Olshansky wrote:
>>>> 20-Sep-2013 14:00, Jacob Carlborg пишет:
>>>>> On 2013-09-20 11:37, Szymon Gatner wrote:
>>>>>
>>>>>> If only std algorithms took containers (by that I mean things that
>>>>>> container for accepts too) as arguments (and not iterators)...
>>>>>> even in the form of new functions like foreach_all, transform_all
>>>>>> etc.
>>>>>
>>>>> Can't a container be a range as well?
>
> A container should not be confused with a range. That way leads to
> dragons. :-P  (It's rather unfortunate that built-in arrays conflate the
> two, it leads to a lot of wrong code that works only with arrays but not
> with "real" ranges.)
>
>
>>>> 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.
>>>
>>> That would be a filtering range which adds additional logic that
>>> costs exactly the same as an if() statement inside a for loop when
>>> filtering on condition manually.
>>>
>> Filtering is just an adapter.
>> Better examples are traversing e.g. binary-tree depth-first
>> in-order, or post-order and that would require state.
>> Again it's easy to miss by looking at built-in arrays.
>
> Traversing the tree at all requires state, whether or not you do it with
> ranges. You either put the state on the runtime stack (recursion), or
> you put the state on the heap in the range adaptor. Same thing.
>
>
>>>> TL;DR: Suboptimal, unnatural and error prone are keywords.
>>>
>>> Why would it be suboptimal?
>>
>> If said tree needs to be a range I would be horrified to see how it
>> manges to be at the same time a range that (for the sake of example)
>> traverses said tree depth-first in-order.
>>
>> Not even talking about trees having no one "natural" range over them.
> [...]
>
> Some trees do, like document trees. But yeah, in general, you don't have
> a natural ordering to trees.

>
> But then again, the whole point of ranges is *linear* traversal. If
> you're not doing that, then it's probably the wrong abstraction to use.

Then traversing all files in directory in specific order is not 
interesting to you? I hardly find that logical. Abstraction is wrong 
only where it doesn't make sense and here it does. There is something 
linear about tree and that is every sane path taken through it is linear 
  (after all there are no cycles).

BTW I see nothing problematic in seeking a minimal set of primitives 
that would allow working on tree-like topology. It won't be the same 
range but never the less useful.

> (FWIW, while SortedRange is a neat hack, I haven't actually found it
> that useful in practice. Most of the ranges I actually use are for the
> cases where it's an input/forward range and you don't want to store the
> whole thing, so random access is impractical.

Sorted forward range is actually fine. You may do interesting things 
with them like O(N+M) merging, subtracting and whatnot. Set operations 
for the win (they are not defined in Phobos yet).

> The cases where I actually
> have random access usually turn out to be plain ole arrays anyway, so
> the SortedRange abstraction isn't really necessary.)
>
> So for trees, I'd argue that you need a tree-specific iteration
> abstraction, not ranges, which are linear. It's a clear case of
> structure conflict. ;-)
>
>
> T
>


-- 
Dmitry Olshansky