It is the year 2020: why should I use / learn D?

[Steven Schveighoffer]

On 11/14/18 1:08 PM, Eugene Wissner wrote:
> On Wednesday, 14 November 2018 at 17:47:10 UTC, Basile B. wrote:
>> On Wednesday, 14 November 2018 at 16:09:32 UTC, Eugene Wissner wrote:
>>> No, it wasn't the reason. Some algorithms cannot be implemented with 
>>> ranges as efficient as with iterators.
>>>
>>> "In other words, by converting the is_word_boundary from iterators to 
>>> D-style ranges, the algorithm goes from O(1) to O(N). From this we 
>>> draw the following conclusion: D’s choice of algorithmic basis 
>>> operations is inherently less efficient than C++’s."
>>>
>>> C++ iterators are more flexible.
>>
>> You meant D ?
> 
> C++. An iterator points to some element in a range, and you can mix it 
> as you need. In D you always have two iterators: beginning and the end 
> of the range. The feature I miss most, is a bidirectional iterator. In 
> C++ you can go back and forth with this iterator. In D if you do popBack 
> there is no way back (or front :)); with popFront you can't reach the 
> element after back, even if there such elements, you have to take an 
> another range from the container.

What you need is an index in a range. The inherent thing about a naked 
iterator (bidirectional or otherwise) is it's not safe. It's super easy 
to get into UB territory.

> D ranges are more compact, because you need the begining and the end in 
> the most cases, so such functions just take one range instead of two 
> iterators. But there are still a lot of cases where D ranges don't work.

It's also much easier to avoid invalid situations with a range vs. 
carrying around 2 iterators. Indeed there are very few cases for 
algorithms that need 3 reference points. But where iterators are great 
are simply as a pointer to an item in a container (see below).

> 
> Steven Schveighoffer mentioned an interesting solution but it adds 
> complexity: Implement Range, ConstRange, Cursor, ConstCursor?, 
> algorithms that accept ranges or cursors and so forth...

Ugh, that's an issue with D and tail-const. You really should never need 
multiple functions for those things, it should just be Range and Cursor, 
and the tail-modified versions should be handled by the language.

But one thing cursors (at least the ones I implemented) don't solve is 
the bidirectional nature -- a cursor is inherently not really movable. 
It needs boundaries to prevent Bad Things, and existentially you don't 
*want* boundaries for a cursor, because boundaries change.

The most common use case I had for a cursor was keeping a reference to 
an element in a container. At various points, I wanted to refer to that 
element to use it, possibly to restructure the container, I didn't want 
to have to search for it again. But if you use an actual range for this, 
you now have *two* elements you are pointing at (the beginning and the 
end). It's entirely possible for that relationship to change or become 
invalid. With a cursor, it can't become invalid because you are only 
pointing at one spot.

-Steve