On 09/19/2011 04:02 PM, Steven Schveighoffer wrote:
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
Ok, makes sense. Thanks.
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?
