On 01/18/2011 07:11 AM, Andrei Alexandrescu wrote:
On 1/17/11 11:48 PM, Jonathan M Davis wrote:
On Monday 17 January 2011 15:13:42 spir wrote:
See range bug evoked above. opApply is the only workaround AFAIK.
Also, ranges cannot yet provide indexed iteration like
foreach(i, char ; text) {...}

While it would be nice at times to be able to have an index with
foreach when
using ranges, I would point out that it's trivial to just declare a
variable
which you increment each iteration, so it's easy to get an index even
when using
foreach with ranges. Certainly, I wouldn't consider the lack of index
with
foreach and ranges a good reason to use opApply instead of ranges.
There may be
other reasons which make it worthwhile, but it's so trivial to get an
index that
the loss of range abilities (particularly the ability to use such
ranges with
std.algorithm) dwarfs it in importance.

- Jonathan M Davis

It's a bit more difficult than that. When iterating a variable-length
encoded range, what you need more than the current item being iterated
is the physical offset reached inside the range. That's not all that
difficult either as the range can always provide an extra primitive, but
a bit annoying (e.g. because it makes iteration with foreach impossible
if you want the index, unless you return a tuple with each step).

This is a very valid point: a range's logical offset is not necessary equal to physical (hum) offset, even on a plain sequence. But for the case of Text it is in fact, precisely because codepoints have been grouped in "piles" each representing true character (grapheme). This is actually one third of the purpose of Text (the others beeing to ensure unique representation of each character, and to provide users with clear interface).
Thus, Jonathan's point simply applies to Text.

At any rate, I agree with two things - one, we need to fix the foreach
situation. Two, even before we find a fix, at this point committing to
iteration with opApply essentially commits the iteratee to an island
where all basic algorithms need to be reinvented from first principles.

I agree. The situation would be different if D had not proposed indexed iteration already, and programmers would routinely count manually and/or call an extra range primitive, as you say.

Upon using opApply: it works fine nevertheless, at least for a first rough implementation like in the case of Text. Reinventing basic algos is not an issue at this stage, as long as they are simple enough, and mainly for testing. (Actually, it can be an advantage in avoiding integration issues, possibly due to D's current beta stage --I mean bugs that pop up only when combinng given features-- like we had eg with range & formatValue).

Andrei

Denis
_________________
vita es estrany
spir.wikidot.com

Reply via email to