digitalmars.D - Lets deprecate the length in the arrays index
- Frank Benoit (keinfarbton) (8/8) Jan 15 2007 There was this thread:
- Lars Ivar Igesund (7/19) Jan 15 2007 I was surprised to hear that this wasn't already deprecated.
- Lionello Lunesu (40/52) Jan 15 2007 I'd like the special case "length" to be removed as much as the next
- Frank Benoit (keinfarbton) (11/11) Jan 15 2007 Actually I do not like this situation:
- Lionello Lunesu (4/15) Jan 15 2007 That's why I said: the compiler should complain.
- janderson (10/61) Jan 15 2007 Gotta say I like this idea. It would make code more manageable if you
- Chris Nicholson-Sauls (13/80) Jan 16 2007 Even though this is just a contrived example, I still have to say that l...
- janderson (20/44) Jan 16 2007 I try to avoid methods for these type of operations when clearly you
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.
Jan 15 2007
Lars Ivar Igesund <larsivar igesund.net> 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
Jan 15 2007
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.
Jan 15 2007
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
Jan 15 2007
"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.
Jan 15 2007
Lionello Lunesu wrote:Frank Benoit (keinfarbton) wrote: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? -JoelThere 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.
Jan 15 2007
janderson wrote:Lionello Lunesu wrote: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-SaulsFrank Benoit (keinfarbton) wrote: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? -JoelThere 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.
Jan 16 2007
Chris Nicholson-Sauls wrote:janderson wrote: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). -JoelLionello Lunesu wrote: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-SaulsFrank Benoit (keinfarbton) wrote:There was this thread:
Jan 16 2007