On Mon, 19 Sep 2011 09:49:14 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:

On 09/19/2011 01:15 PM, Steven Schveighoffer wrote:
On Sun, 18 Sep 2011 16:16:23 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:

On 09/18/2011 10:09 PM, Andrei Alexandrescu wrote:
On 9/18/11 2:46 PM, Nick Sabalausky wrote:
"Timon Gehr"<timon.g...@gmx.ch> wrote in message
news:j55h4f$1ia5$1...@digitalmars.com...

The only advantages slices have left
are (a) type syntax, i.e. T[] instead of Slice!T, (b) literal syntax, i.e. [ 1, 2, 3 ] instead of slice(1, 2, 3), and (c) a couple of stray
language bugs such as '$'.

I am thankful for $, as it is a great feature, and it really should be made accessible to user defined types. Either through opDollar or the
rewrite a[foo($)] => a[foo(a.length)]. What makes it qualify as a
stray
language bug to you?


He's saying that one of the few advantages slices have left over
user-defined types is that, for slices, $ actually works. The bug is
that it
doesn't work for user-defined types.

FWIW, I like the rewrite idea far better than opDollar.

opDollar is more powerful because it can be made to work with infinite
ranges.

Andrei

What would it return?

Not all types that have an end also support .length, or use sequential
integers for indexes.

-Steve

Yes, but D has already gone the 'being inflexible' path for the comparison/negation/logical/ternary operators. Isn't this a similar thing? I don't think infinite ranges work well with restrictive operator overloading. eg a[0..100<$?100:$]. They'd need some additional language support or they'll possibly blow up randomly on generic code.

Btw, do you know of an example of a data structure that can be indexed continuously and has the notion of an end, but no length?

I was specifically thinking of red-black tree, which has a distinct end, but it's index is not necessarily length (or any value for that matter).

If you look at dcollections, you can slice a TreeMap using indexes or cursors. However, to index through the last element in the tree, you use the special cursor .end:

auto range = mytree["hello" .. mytree.end]; // get all the elements in the tree which are >= "hello"

Here, mytree["hello" .. mytree.length] would simply not compile.

In addition, a tree with a uint index would silently do the *wrong* thing:

auto set = new TreeSet!uint(1, 3, 5, 7, 9);
assert(set.length == 5);
auto range = set[1..set.length];

assert(walkLength(range) == 2); // probably not what you expected

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.

-Steve

Reply via email to