On 2/28/2013 1:19 AM, Peter Alexander wrote:
On Thursday, 28 February 2013 at 01:12:19 UTC, Walter Bright wrote:
Motivation:
1. easy conversion of C strings to ranges
This is already easy.
struct CString
{
@property char front() { return *p; }
void popFront() { ++p; }
@property bool empty() const { return !*p; }
char* p;
}
(Yep, rubbish implementation, missing save, constructors etc., but you get the
idea).
Notice the double read of *p. This is what SentinelInputRange is trying to fix.
2. necessary for a fast implementation of a lexer
This is very domain specific. Is a whole new range concept in the standard
library necessary?
I've posted in this thread several use cases.
My worry here is that we are setting a precedent for adding new range concepts.
If the only justification needed is that is saves a single operation in some
niche area of computing then we are opening the door to a LOT of different range
concepts.
There are many cases where speed is a very big deal.
Are there any other REAL uses for this other than in one line of a lexer
implementation? I think inclusions into the standard library should require at
least several distinct and realistic use cases.
I've posted several - including one in Phobos.