[Issue 7177] $ should forward to length by default

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Mar 21 07:30:58 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #14 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-03-21 07:30:56 PDT ---
(In reply to comment #12)
> If you have a type which defines length and has slicing or indexing, does it
> make any sense whatsoever for length _not_ to be the same as opDollar? I'd
> strongly argue that any type (be it a range or otherwise) which had indexing or
> slicing and had length and made opDollar something else other than length (or
> length something else than one past the last index) would be very badly
> designed.

Yes, it makes sense in some cases for opDollar not to be length.

In the case of dcollections, I want opDollar to map to .end() (which is the
last cursor), not .length.  Please don't make $ map to .length, it will break
current dcollections.

Example:

I allow slicing based on index for TreeMap, because indexes are in order.  This
code, would potentially compile, but return the unexpected slice of half the
elements in the TreeMap:

auto m = new TreeMap!(int, int);
m[0] = 0;
m[2] = 2;
m[4] = 4;
m[6] = 6;
assert(m.length == 4);
auto sl = m[0..$]; // translates to m[0..m.length];
assert(sl.walkLength() == 2); // only 2 elements!

What I would like is for $ to map to m.end().

Another example is int[int]:

int[int] x;
x[1] = 14;
x[100] = 42;
assert(x[$-1] == 14);

if $ maps to x.length, then it happens to coincide with x[1], but that isn't
necessarily the "last" element in the AA (which is how it reads).  In fact, I
would argue x[$-1] shouldn't compile, it's value is meaningless.

Sorry that it makes you have to add boilerplate, but I think it's incorrect to
always equate length with $.

The boilerplate isn't actually that bad, it's just an alias.  In generated code
it adds NO bloat.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list