There was this thread:

22-Oct-2005
It's time to deprecate "array [length]" in favour of "array [$]"

Actually I noticed, i still can use length inside an array index, even if compiling without -d (deprecated).

For me that means, I do not use the identifier 'length' in D. For nothing. Because it can happen, it collides with this array stranger.

Please remove this or deprecated this.

Frank Benoit (keinfarbton) wrote:

> There was this thread:
> 
> 22-Oct-2005
> It's time to deprecate "array [length]" in favour of "array [$]"
> 
> Actually I noticed, i still can use length inside an array index, even if compiling without -d (deprecated).
> 
> For me that means, I do not use the identifier 'length' in D. For nothing. Because it can happen, it collides with this array stranger.
> 
> Please remove this or deprecated this.

I was surprised to hear that this wasn't already deprecated.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango

Frank Benoit (keinfarbton) wrote:
> There was this thread:
> 
> 22-Oct-2005
> It's time to deprecate "array [length]" in favour of "array [$]"
> 
> Actually I noticed, i still can use length inside an array index, even
> if compiling without -d (deprecated).
> 
> For me that means, I do not use the identifier 'length' in D. For
> nothing. Because it can happen, it collides with this array stranger.
> 
> Please remove this or deprecated this.

I'd like the special case "length" to be removed as much as the next guy, but actually, I think it would be nicer to generalize it: why not let the brackets [..] be treated as an implicit with()? I mean, inside the brackets you have the context of the thing before the brackets:

array[identifier];
//=>
with(array)
  opIndex(identifier);
//and
array[ident1..ident2];
//=>
with(array)
  opSlice(ident1,ident2);

(ATM, 'with' only accepts class objects)

This gets rid of the special case and makes it available to class object:

import std.stdio;
class X {
    uint length;
    char[] opIndex(uint x) { return "index"; }
    char[][] opSlice(uint f,uint t) { return ["op","slice"]; }
}
void main()
{
    auto x = new X;
    writefln(x[length-1]);    // now needs x.length
    writefln(x[0..length-1]); // now needs x.length
    writefln(x[$-1]);
    writefln(x[0..$-1]);

    with(x) {
        writefln( opIndex(length-1) );
        writefln( opSlice(0,length-1) );
        int length = 23;      // compiler does not complain :(
    }
}

Note that if X were to have a member "uint first", I would be able to do  "x[first]".

Ideally, the compiler would complain if an ambiguous symbol was being used inside with (and [], [..]).

L.

Actually I do not like this situation:

int length = 3;
int[] a = getData();
writefln( "%d\n", a[length] ); // which length?


And I definitely never want to run in this situation:

class A{
  public int size(){ return 0; }
}

int size = 3;
A a = getData();
writefln( "%d\n", a[size-3] ); // woops, A defines size also

"Frank Benoit (keinfarbton)" <benoit@tionex.removethispart.de> wrote in message news:eogc6d$1tsn$1@digitaldaemon.com...
>
> Actually I do not like this situation:
>
> int length = 3;
> int[] a = getData();
> writefln( "%d\n", a[length] ); // which length?
>
>
> And I definitely never want to run in this situation:
>
> class A{
>  public int size(){ return 0; }
> }
>
> int size = 3;
> A a = getData();
> writefln( "%d\n", a[size-3] ); // woops, A defines size also

That's why I said: the compiler should complain.

L.

Lionello Lunesu wrote:
> Frank Benoit (keinfarbton) wrote:
>> There was this thread:
>>
> 
> I'd like the special case "length" to be removed as much as the next guy, but actually, I think it would be nicer to generalize it: why not let the brackets [..] be treated as an implicit with()? I mean, inside the brackets you have the context of the thing before the brackets:
> 
> array[identifier];
> //=>
> with(array)
>   opIndex(identifier);
> //and
> array[ident1..ident2];
> //=>
> with(array)
>   opSlice(ident1,ident2);
> 
> (ATM, 'with' only accepts class objects)
> 
> This gets rid of the special case and makes it available to class object:
> 
> import std.stdio;
> class X {
>     uint length;
>     char[] opIndex(uint x) { return "index"; }
>     char[][] opSlice(uint f,uint t) { return ["op","slice"]; }
> }
> void main()
> {
>     auto x = new X;
>     writefln(x[length-1]);    // now needs x.length
>     writefln(x[0..length-1]); // now needs x.length
>     writefln(x[$-1]);
>     writefln(x[0..$-1]);
> 
>     with(x) {
>         writefln( opIndex(length-1) );
>         writefln( opSlice(0,length-1) );
>         int length = 23;      // compiler does not complain :(
>     }
> }
> 
> Note that if X were to have a member "uint first", I would be able to do  "x[first]".
> 
> Ideally, the compiler would complain if an ambiguous symbol was being used inside with (and [], [..]).
> 
> L.

Gotta say I like this idea.  It would make code more manageable if you could do things like:

char[] value = line[find('a')+1..find_r('b')];

instead of,

char[] value = line[line.find('a')+1..line.find_r('b')];

Although in something like the above you'd want to make sure that both a and b exist before doing these searches.  Playing the D advocate for a second, maybe we don't want to encourage this style of coding?

-Joel

janderson wrote:
> Lionello Lunesu wrote:
>> Frank Benoit (keinfarbton) wrote:
>>> There was this thread:
>>>
>>
>> I'd like the special case "length" to be removed as much as the next guy, but actually, I think it would be nicer to generalize it: why not let the brackets [..] be treated as an implicit with()? I mean, inside the brackets you have the context of the thing before the brackets:
>>
>> array[identifier];
>> //=>
>> with(array)
>>   opIndex(identifier);
>> //and
>> array[ident1..ident2];
>> //=>
>> with(array)
>>   opSlice(ident1,ident2);
>>
>> (ATM, 'with' only accepts class objects)
>>
>> This gets rid of the special case and makes it available to class object:
>>
>> import std.stdio;
>> class X {
>>     uint length;
>>     char[] opIndex(uint x) { return "index"; }
>>     char[][] opSlice(uint f,uint t) { return ["op","slice"]; }
>> }
>> void main()
>> {
>>     auto x = new X;
>>     writefln(x[length-1]);    // now needs x.length
>>     writefln(x[0..length-1]); // now needs x.length
>>     writefln(x[$-1]);
>>     writefln(x[0..$-1]);
>>
>>     with(x) {
>>         writefln( opIndex(length-1) );
>>         writefln( opSlice(0,length-1) );
>>         int length = 23;      // compiler does not complain :(
>>     }
>> }
>>
>> Note that if X were to have a member "uint first", I would be able to do  "x[first]".
>>
>> Ideally, the compiler would complain if an ambiguous symbol was being used inside with (and [], [..]).
>>
>> L.
> 
> Gotta say I like this idea.  It would make code more manageable if you could do things like:
> 
> char[] value = line[find('a')+1..find_r('b')];
> 
> instead of,
> 
> char[] value = line[line.find('a')+1..line.find_r('b')];
> 
> Although in something like the above you'd want to make sure that both a and b exist before doing these searches.  Playing the D advocate for a second, maybe we don't want to encourage this style of coding?
> 
> -Joel

Even though this is just a contrived example, I still have to say that line ought to just expose a method for this operation, perhaps a findSlice(a,b).  If and when we get Tuples as return values one could also use that if you wanted to keep the find and slice operations seperated.

I'm just very wary of the []==with concept.  Its unintuitive, still causes the same namespace issues as [length], and even creates new ones.  Honestly, I've often wondered if something other than the dot operator should be found for built-in properties (and even for non built-in ones, but that goes back to my desire for an explicit property syntax, alas).  Sadly, I have no idea what else to use, except maybe a colon (:) but that poor baby is getting burdened already, and could still be ambiguous (consider `case int.max: ...;` versus `case int:max: ...;` -- ack).

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> janderson wrote:
>> Lionello Lunesu wrote:
>>> Frank Benoit (keinfarbton) wrote:
>>>> There was this thread:
>>>>
>>>
> 
> Even though this is just a contrived example, I still have to say that line ought to just expose a method for this operation, perhaps a findSlice(a,b).  If and when we get Tuples as return values one could also use that if you wanted to keep the find and slice operations seperated.
> 
> I'm just very wary of the []==with concept.  Its unintuitive, still causes the same namespace issues as [length], and even creates new ones.  Honestly, I've often wondered if something other than the dot operator should be found for built-in properties (and even for non built-in ones, but that goes back to my desire for an explicit property syntax, alas).  Sadly, I have no idea what else to use, except maybe a colon (:) but that poor baby is getting burdened already, and could still be ambiguous (consider `case int.max: ...;` versus `case int:max: ...;` -- ack).
> 
> -- Chris Nicholson-Sauls

I try to avoid methods for these type of operations when clearly you have access to all you need outside the class.  Free functions are so much more manageable and reuseable.  This is particularly the case if the array was in some stand lib.

I'm not to worried about the namespacing issue, you still could use the . operator if you need to.   Of course there's the issue of case-sensitive and type-o errors, but must coders are used to dealing with them.

I do agree that a findSlice would be a good idea, however if you look at the internals, you end up writing the longer bit of code again.  Of course I would recommend it being written safely like:

int first = line.find('a');
int last = line.find('b');

if (first < last)
{
   return line[first...last];
}

ect... (or throw an exception or whatever).

-Joel