Ranges

[Jonathan M Davis]

On Friday 18 March 2011 02:29:51 Peter Alexander wrote:
> On 13/03/11 12:05 AM, Jonathan M Davis wrote:
> > So, when you're using a range of char[] or wchar[], you're really using a
> > range of dchar. These ranges are bi-directional. They can't be sliced,
> > and they can't be indexed (since doing so would likely be invalid). This
> > generally works very well. It's exactly what you want in most cases. The
> > problem is that that means that the range that you're iterating over is
> > effectively of a different type than the original char[] or wchar[].
> 
> This has to be the worst language design decision /ever/.
> 
> You can't just mess around with fundamental principles like "the first
> element in an array of T has type T" for the sake of a minor
> convenience. How are we supposed to do generic programming if common
> sense reasoning about types doesn't hold?
> 
> This is just std::vector<bool> from C++ all over again. Can we not learn
> from mistakes of the past?

It really isn't a problem for the most part. You just need to understand that 
when using range-based functions, char[] and wchar[] are effectively _not_ 
arrays. They are ranges of dchar. And given the fact that it really wouldn't 
make sense to treat them as arrays in this case anyway (due to the fact that a 
single element is a code unit but _not_ a code point), the current solution 
makes a lot of sense. Generally, you just can't treat char[] and wchar[] as 
arrays when you're dealing with characters/code points rather than code units. 
So, yes it's a bit weird, but it makes a lot of sense given how unicode is 
designed. And it works.

If you really don't want to deal with it, then just use dchar[] and dstring 
everywhere.

- Jonathan M Davis