Go and generic programming on reddit, also touches on D

Timon Gehr timon.gehr at gmx.ch
Mon Sep 19 07:24:33 PDT 2011


On 09/19/2011 04:02 PM, Steven Schveighoffer wrote:
> On Mon, 19 Sep 2011 09:49:14 -0400, Timon Gehr <timon.gehr at 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.gehr at 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.gehr at gmx.ch> wrote in message
>>>>>> news:j55h4f$1ia5$1 at 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?




More information about the Digitalmars-d mailing list