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?
