First practice:
char[] text;
char* p;
char* end;
Version1:
p=text.ptr;
end= text.ptr+length;
we use p to scan over the text, and end as a mark.
Version2:
text[blah] to scan over the text.
Obviously version 2 is cleaner, but slower.

Don't be so sure. Did you measure it?
And don't forget Version3:
foreach(c; text)
{ ... }
Supposedly generates code as efficient as a for loop.

Pointer arithmetic in D is a no-no, unless you are using memory
allocated outside of the GC.

That's news to me. There's nothing wrong with using pointers, it's just
more verbose and error prone than foreach.

Of course there's nothing wrong with /using/ pointers, but pointer
arithmetic is one item in a list of 'Undefined Behavior' regarding
pointers to GC memory. See the page
http://www.digitalmars.com/d/garbage.html (section titled Pointers and
the Garbage Collector).
This isn't really an issue in the present since the current GC doesn't
move anything around, AFAIK. But it's still a bad habit to get into (or
a good one to get out of for people with C backgrounds) and doesn't do
much for future-proofing.

Pointer arithmetic in D is a no-no, unless you are using memory
allocated outside of the GC.

That's news to me. There's nothing wrong with using pointers, it's
just more verbose and error prone than foreach.

Of course there's nothing wrong with /using/ pointers, but pointer
arithmetic is one item in a list of 'Undefined Behavior' regarding
pointers to GC memory. See the page
http://www.digitalmars.com/d/garbage.html (section titled Pointers and
the Garbage Collector).
This isn't really an issue in the present since the current GC doesn't
move anything around, AFAIK. But it's still a bad habit to get into (or
a good one to get out of for people with C backgrounds) and doesn't do
much for future-proofing.

Hmm. I could have sworn I had read something explicitly saying that any
pointer arithmetic was bad. Looking at it again, the only related items
I see are the following:
"Do not add or subtract an offset to a pointer such that the result
points outside of the bounds of the garbage collected object originally
allocated."
and
"Do not use byte-by-byte memory copies to copy pointer values. This may
result in intermediate conditions where there is not a valid pointer,
and if the gc pauses the thread in such a condition, it can corrupt memory."
Maybe there was something about this in the NG before? Or maybe I
interpreted the item above as ruling out the incrementing of pointers.

Pointer arithmetic in D is a no-no, unless you are using memory
allocated outside of the GC.

That's news to me. There's nothing wrong with using pointers, it's
just more verbose and error prone than foreach.

Of course there's nothing wrong with /using/ pointers, but pointer
arithmetic is one item in a list of 'Undefined Behavior' regarding
pointers to GC memory. See the page
http://www.digitalmars.com/d/garbage.html (section titled Pointers and
the Garbage Collector).

I can't see anything about pointer arithmetic in that section. Did I miss it?
As I read it, the basic rule is that pointers must stay as pointers at all
times, and you can't subtract pointers that point to unrelated objects.
Pointers that are pointing to different parts of the same block of memory (eg
the same array) could be changed by the gc, but they'll all be moved in the
same
way, so everything should still be OK.

This isn't really an issue in the present since the current GC doesn't
move anything around, AFAIK. But it's still a bad habit to get into (or
a good one to get out of for people with C backgrounds) and doesn't do
much for future-proofing.

Problem is, the code davidl is trying to do is a port of DMD's front-end
from C++ to D. It's a little counterintuitive: "Don't use pointer
arithmetic in D, but it helped me a little to make DMD's front-end more
readable and efficient." :-P
This is just a guess, but I think davidl is looking for a way to iterate
over the chars of an array, like in a lexer, as efficient and as nice
(beauty of code) as possible.

Pointer arithmetic in D is a no-no, unless you are using memory
allocated outside of the GC.

What makes you say that?
Playing with pointers is perfectly valid and safe in D, as long as
you keep to the rules in http://www.digitalmars.com/d/garbage.html
(and currently, in paractice, even quite a bit further)!
Please, would everyone chip in and try to keep wrong assertions in
the ng to a minimum, so as not to confuse (other) newcomers!
Regards, Frank

Pointer arithmetic in D is a no-no, unless you are using memory
allocated outside of the GC.

What makes you say that?
Playing with pointers is perfectly valid and safe in D, as long as
you keep to the rules in http://www.digitalmars.com/d/garbage.html
(and currently, in paractice, even quite a bit further)!
Please, would everyone chip in and try to keep wrong assertions in
the ng to a minimum, so as not to confuse (other) newcomers!
Regards, Frank

Yes, yes. I've already posted that I was mistaken about having read it
in the spec. But I really was convinced I had seen something about this
in that same page about the GC, the NG, or somewhere. I wasn't making it
up or intentionally making a 'wrong assertion.'

Yes, yes. I've already posted that I was mistaken about having read it

Yes, I've seen it, but too late... I admit I should probably have read
/all/ posts first befor answering any of them. But even when there are
still a dozen unread, the reflex is still to answer them as you read them.
Atually I have retracted a second posting I wrote after reading
news://news.digitalmars.com:119/fen6co$tj8$1 digitalmars.com
and before you finally wrote
news://news.digitalmars.com:119/fen7fj$15vm$1 digitalmars.com .
But at this point of time I felt it was too late to retract my first
posting, so I decided to sit it out and write this reply if needed. :)

I wasn't making it up or intentionally making a 'wrong assertion.'

Sorry, I have not tried to imply you were making things up or intent-
ionally making wrong assertions! I just wanted to remind us all to be
on our guard and only assert things of which we think we really quite
reliably know about - taken into account we all make mistakes.
In my retracted post I wrote beside other things "Wow, we're even
calling on the same piece of text to bolster our opposite opinions!
Maybe the case is not quite as clear as I thought.".
Regards, Frank