Go and generic programming on reddit, also touches on D

Timon Gehr timon.gehr at gmx.ch
Mon Sep 19 06:49:14 PDT 2011


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?





More information about the Digitalmars-d mailing list