On Mon, 19 Sep 2011 10:24:33 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:
On 09/19/2011 04:02 PM, Steven Schveighoffer wrote:
So I think it's not only limiting to require x.length to be $, it's very
wrong in some cases.
Also, think of a string. It has no length (well technically, it does,
but it's not the number of elements), but it has a distinct end point. A
properly written string type would fail to compile if $ was s.length.
But you'd have to compute the length anyways in the general case:
str[0..$/2];
Or am I misunderstanding something?
That's half the string in code units, not code points.
If string was properly implemented, this would fail to compile. $ is not
the length of the string range (meaning the number of code points). The
given slice operation might actually create an invalid string.
It's tricky, because you want fast slicing, but only certain slices are
valid. I once created a string type that used a char[] as its backing,
but actually implemented the limitations that std.range tries to enforce
(but cannot). It's somewhat of a compromise. If $ was mapped to
s.length, it would fail to compile, but I'm not sure what I *would* use
for $. It actually might be the code units, which would not make the
above line invalid.
-Steve
