Are iterators and ranges going to co-exist?

[KennyTM~]

On Jul 22, 10 11:56, Walter Bright wrote:
> Peter Alexander wrote:
>> == Quote from Walter Bright (newshound2 at digitalmars.com)'s article
>>> If some algorithms used ranges and others used iterators, the
>> poor programmer
>>> would find himself then obliged to implement both interfaces for
>> each container.
>>
>> This makes no sense.
>>
>> I don't understand why you see ranges and iterators as conflicting
>> concepts. The cursors/iterators are for referring to individual
>> elements, and ranges are for specifying iterations over a sequence.
>
> Right, so the container programmer is obliged to implement both.
>
>
>> There aren't two competing interfaces here. If your interface
>> requires a range of elements, you use a range. If it only needs a
>> single element, you use a cursor.
>
> The algorithm is the one doing the requiring, not the container. So, if
> there are standard algorithms some of which require ranges and others
> that require interfaces, the container implementor is obliged to provide
> both.
>
>
>>>> All I would like to see is some way to generically point to a
>>>> single element in a range.
>>> range[0] ?
>> That only works on arrays, therefore it is not generic.
>
> Any range can provide a [0] interface.
>

I think it's actually ".front".

>
>>> There is the massive unsafeness of using iterators. We'd like
>> the whole of the
>>> algorithms to be guaranteed memory safe, and that cannot happen
>> with iterators.
>>> Being able to statically guarantee memory safety is a huge deal,
>> and the larger
>>> a program is and the larger the team working on it, the more
>> this matters.
>>
>> The iterators would not need to be used for iterations.
>
> Perhaps calling them iterators, then, is a source of confusion!