std.d.lexer requirements
Jonathan M Davis
jmdavisProg at gmx.com
Thu Aug 2 15:54:34 PDT 2012
On Thursday, August 02, 2012 18:41:23 Andrei Alexandrescu wrote:
> On 8/2/12 6:38 PM, Jonathan M Davis wrote:
> > On Thursday, August 02, 2012 15:14:17 Walter Bright wrote:
> >> Remember, its the consumer doing the decoding, not the input range.
> >
> > But that's the problem. The consumer has to treat character ranges
> > specially to make this work. It's not generic.
>
> It is generic! It's just in another dimension: it operates on any range
> of _bytes_.
So, a function which does the buffering of code units like Walter suggests is
generic? It's doing something that makes no sense outside of strings. And if
it's doing that with strings and something else with everything else (which it
_has_ to do if the same function is going to work with both unicode as well as
range types that have nothing to do with unicode), then it's special casing
strings and therefore is _not_ generic.
Sure, you could have a function which specifically operates on ranges of code
units and understands how unicode works and is written accordingly, but then
that function is specific to ranges of code units and is only generic with
regards to various ranges of code units. It can't operate on generic ranges
like functions such as map and filter can.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list