September 18, 2011
On 9/18/11 2:34 PM, Timon Gehr wrote:
> On 09/18/2011 08:28 PM, Andrei Alexandrescu wrote:
>> On 9/18/11 11:08 AM, Timon Gehr wrote:
>>> On 09/18/2011 03:48 AM, Andrei Alexandrescu wrote:
>>>> Quite interesting.
>>>>
>>>> http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/
>>>>
>>> 2 hours ago, Andrei Alexandrescu wrote:
>>> > The problem is, Vector was just an example of a multitude of
>>> containers. The huge problem with slices is dogfood-related - they are >
>>> "magic" because the language features proposed to programmers were not
>>> enough for expressing a simple abstraction. Reserving "special" features
>>> for the language is a terrible way to go about programming language
>>> design.
>>>
>>> Don't D arrays do a similar thing? They are not templates, yet work with
>>> generic element types.
>>>
>>> Afaics, improving the language to the point were dynamic array-like
>>> structures could be implemented in the library without resulting in a
>>> bloated executable would be quite involved.
>>
>> That's an incorrect view of my statement.
>
> I don't think so.

You're free to think anything, but I know what I said and your view of it is incorrect.

Andrei
September 18, 2011
On 09/18/2011 09:46 PM, Nick Sabalausky wrote:
> "Timon Gehr"<timon.gehr@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.

OK, thanks for clarifying.
(I would have called that an implementation bug though)

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

Me too. It fits better in the picture of D operator overloading.

September 18, 2011
On 9/18/11 2:46 PM, Nick Sabalausky wrote:
> "Timon Gehr"<timon.gehr@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
September 18, 2011
On 09/18/2011 10:09 PM, Andrei Alexandrescu wrote:
> On 9/18/11 2:46 PM, Nick Sabalausky wrote:
>> "Timon Gehr"<timon.gehr@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?




September 18, 2011
On 9/18/2011 4:09 PM, Andrei Alexandrescu wrote:
> opDollar is more powerful because it can be made to work with infinite
> ranges.
>
> Andrei

Yes, this is important.  IMHO, though, the default behavior of the $ operator should be to call range.length if it exists and opDollar isn't explicitly overloaded.  This would save a lot of boilerplate.
September 18, 2011
On 09/18/2011 10:06 PM, Andrei Alexandrescu wrote:
> On 9/18/11 2:34 PM, Timon Gehr wrote:
>> On 09/18/2011 08:28 PM, Andrei Alexandrescu wrote:
>>> On 9/18/11 11:08 AM, Timon Gehr wrote:
>>>> On 09/18/2011 03:48 AM, Andrei Alexandrescu wrote:
>>>>> Quite interesting.
>>>>>
>>>>> http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/
>>>>>
>>>>>
>>>> 2 hours ago, Andrei Alexandrescu wrote:
>>>> > The problem is, Vector was just an example of a multitude of
>>>> containers. The huge problem with slices is dogfood-related - they
>>>> are >
>>>> "magic" because the language features proposed to programmers were not
>>>> enough for expressing a simple abstraction. Reserving "special"
>>>> features
>>>> for the language is a terrible way to go about programming language
>>>> design.
>>>>
>>>> Don't D arrays do a similar thing? They are not templates, yet work
>>>> with
>>>> generic element types.
>>>>
>>>> Afaics, improving the language to the point were dynamic array-like
>>>> structures could be implemented in the library without resulting in a
>>>> bloated executable would be quite involved.
>>>
>>> That's an incorrect view of my statement.
>>
>> I don't think so.
>
> You're free to think anything, but I know what I said and your view of
> it is incorrect.
>
> Andrei

Well, I'd say there was a misunderstanding. Understanding someone who is not explaining himself is particularly difficult, so it is quite possible I am the one who misunderstood. But if you lack the time or motivation to carry out this discussion, that is fine of course.


September 18, 2011
On 9/18/2011 4:16 PM, Timon Gehr wrote:
> What would it return?

A dummy type, e.g.:

struct Repeat(T) {
    T val;
    T front() @property { return val; }
    void popFront() {}
    enum empty = false;

    static struct Dollar {}
    Dollar opDollar() {
        return Dollar.init;
    }


    auto opSlice(size_t lower, Dollar dollar) { return this; }
}

void main() {
    auto r = Repeat!int(1);
    auto r2 = r[666..$];
}
September 18, 2011
On 9/18/11 3:19 PM, dsimcha wrote:
> On 9/18/2011 4:09 PM, Andrei Alexandrescu wrote:
>> opDollar is more powerful because it can be made to work with infinite
>> ranges.
>>
>> Andrei
>
> Yes, this is important. IMHO, though, the default behavior of the $
> operator should be to call range.length if it exists and opDollar isn't
> explicitly overloaded. This would save a lot of boilerplate.

struct MyRange
{
  ...
  alias length opDollar;
}

I do agree that most of the time this is what you want anyway, so that line would occur a lot of times...


Andrei
September 18, 2011
On 09/18/2011 10:21 PM, dsimcha wrote:
> On 9/18/2011 4:16 PM, Timon Gehr wrote:
>> What would it return?
>
> A dummy type, e.g.:
>
> struct Repeat(T) {
> T val;
> T front() @property { return val; }
> void popFront() {}
> enum empty = false;
>
> static struct Dollar {}
> Dollar opDollar() {
> return Dollar.init;
> }
>
>
> auto opSlice(size_t lower, Dollar dollar) { return this; }
> }
>
> void main() {
> auto r = Repeat!int(1);
> auto r2 = r[666..$];
> }

Ok, but what about

void main(){
    auto r = Repeat!int(1);
    auto r2 = r[666..$-1]; // ok, return entire range
    auto r3 = r[666..$/2]; // ditto
    auto r4 = r[666..$<100?$:100]; // ???
    // those could be made illegal:
    auto r5 = r[666..$*0]; // ???
    auto r6 = r[666..$-$]; // ???
    auto r7 = r[666..2*$-$]; // ???
    auto r8 = r[666..($*$)%4==3?667:668]; // ???
}







September 18, 2011
On Sun, 18 Sep 2011 22:09:19 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 9/18/11 2:46 PM, Nick Sabalausky wrote:
>> "Timon Gehr"<timon.gehr@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.

Also, multi-dimensional structures:

    RectangularArray!int a = [[1,2,3], [4,5,6,7]];
    int b = a[$-1, $-2];

Those are obviously different $s.

-- 
  Simen