• Frank Benoit <keinfarbton googlemail.com> Mar 15 2008
• "Janice Caron" <caron800 googlemail.com> Mar 15 2008
• Bill Baxter <dnewsgroup billbaxter.com> Mar 15 2008
• Robert Fraser <fraserofthenight gmail.com> Mar 15 2008
• Bill Baxter <dnewsgroup billbaxter.com> Mar 15 2008
• Robert Fraser <fraserofthenight gmail.com> Mar 15 2008
• Pedro Ferreira <ask me.pt> Mar 18 2008
• Jesse Phillips <jessekphillips gmail.com> Mar 18 2008
• Frank Benoit <keinfarbton googlemail.com> Mar 22 2008

Frank Benoit <keinfarbton googlemail.com> writes:

Given this array:
	int[] bar = new int[4];

This is equivalent:
	bar[ 1 .. length ] <->  bar[ 1 .. $ ]
	bar[ length -1 ]   <->  bar[ $-1 ]

'length' is implicitely declared within [ ].

Since long time i think 'length' should be removed, because it can 
conflict with a local 'length' variable. We have the special symbol $, 
which does not have this problem.

I think this matters in case of porting code. 'length' is an often used 
variable name, especially in code portions acting with arrays. When 
porting such stuff, all 'length' variables need to be renamed.

But i see no benefit from this 'length'. It seems surprising for me. I 
always use $. When i see foreign code using 'length', it looks wrong to me.

Implicit 'length' does implicitely disallow the name 'length' for all 
other integer like variables that are potentially used in array index 
calculations. In fact, i don't use the name 'length' for any variable in 
D because of this.

I wish, the implicit 'length' would be deprecated and then removed from D.

Summay:
  - One thing/rule more to keep in mind
  - No benefit
  - It exists because it existed before we had $
  - Can cause problems
  - Restricts the use of the name 'length' for other variables.

Removing 'length' would not break code in unexpected ways. It would 
yield compile errors in every case and can be fixed by simple replacing 
'length' to '$'.

"Janice Caron" <caron800 googlemail.com> writes:

On 15/03/2008, Frank Benoit <keinfarbton googlemail.com> wrote:
  Removing 'length' would not break code in unexpected ways. It would
  yield compile errors in every case and can be fixed by simple replacing
  'length' to '$'.


I'm inclined to agree. "length" is a property all arrays. You can say,
for example,

    int n = array.length;

but not

    int n = array.$;

However, within array square brackets, "length" implicitly means
"array.length", and this is unlike any other member variable in D. For
example, the following will not compile:

    auto array = new int[4];
    int n = array[ptr-ptr];

Both "length" and "ptr" are member variables of array, but within
those square brackets, "length" is implicitly known, and "ptr" is not.
That's inconsistent. And as Frank said, it's been superceded by "$".

BUT...

I want to be able to create containers that behave just like the built
in ones. That means, I want the $ symbol to be allowed within the
square brackets of user-defined structs and classes, and that it
should call the member function length() when referenced. I see that
as a critical piece of the jigsaw.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Janice Caron wrote:

 I want to be able to create containers that behave just like the built
 in ones. 


Happy Easter!

struct EndRelativeIndex {
     /** $ - 5  */
     EndRelativeIndex opSub(int off_) {
         EndRelativeIndex R = *this;
         R.offset -= off_;
         return R;
     }
     /** $ + 5 */
     EndRelativeIndex opAdd(int off_) {
         EndRelativeIndex R = *this;
         R.offset += off_;
         return R;
     }
     /** 5 + $ */
     EndRelativeIndex opAdd_r(int off_) {
         EndRelativeIndex R = *this;
         R.offset += off_;
         return R;
     }
private:
     int offset = 0;
}
EndRelativeIndex _end;

// Easter egg here:
alias _end __dollar;

struct Array(T)
{
     T opIndex(size_t i) { return data[i]; }
     T opIndex(EndRelativeIndex i) { return data[data.length+i.offset]; }

     T[] data;
}

void main() {
     Array!(int) x;
     x.data = [1,2,3,4,5];

     assert(x[0] == 1);
     assert(x[$-1] == 5);
     assert(x[$-2] == 4);
}

--bb

Robert Fraser <fraserofthenight gmail.com> writes:

Wow, my head asplode! That's awesome! It'd stil be nicer to have it as part of
the language rather than an undocumented trick.

Bill Baxter Wrote:

 Janice Caron wrote:
 
 I want to be able to create containers that behave just like the built
 in ones. 


 Happy Easter!
 
 struct EndRelativeIndex {
      /** $ - 5  */
      EndRelativeIndex opSub(int off_) {
          EndRelativeIndex R = *this;
          R.offset -= off_;
          return R;
      }
      /** $ + 5 */
      EndRelativeIndex opAdd(int off_) {
          EndRelativeIndex R = *this;
          R.offset += off_;
          return R;
      }
      /** 5 + $ */
      EndRelativeIndex opAdd_r(int off_) {
          EndRelativeIndex R = *this;
          R.offset += off_;
          return R;
      }
 private:
      int offset = 0;
 }
 EndRelativeIndex _end;
 
 // Easter egg here:
 alias _end __dollar;
 
 struct Array(T)
 {
      T opIndex(size_t i) { return data[i]; }
      T opIndex(EndRelativeIndex i) { return data[data.length+i.offset]; }
 
      T[] data;
 }
 
 void main() {
      Array!(int) x;
      x.data = [1,2,3,4,5];
 
      assert(x[0] == 1);
      assert(x[$-1] == 5);
      assert(x[$-2] == 4);
 }
 
 --bb

Bill Baxter <dnewsgroup billbaxter.com> writes:

Frank Benoit wrote:
 Given this array:
     int[] bar = new int[4];
 
 This is equivalent:
     bar[ 1 .. length ] <->  bar[ 1 .. $ ]
     bar[ length -1 ]   <->  bar[ $-1 ]
 
 'length' is implicitely declared within [ ].
 
 Since long time i think 'length' should be removed, because it can 
 conflict with a local 'length' variable. We have the special symbol $, 
 which does not have this problem.
 
 I think this matters in case of porting code. 'length' is an often used 
 variable name, especially in code portions acting with arrays. When 
 porting such stuff, all 'length' variables need to be renamed.
 
 But i see no benefit from this 'length'. It seems surprising for me. I 
 always use $. When i see foreign code using 'length', it looks wrong to me.
 
 Implicit 'length' does implicitely disallow the name 'length' for all 
 other integer like variables that are potentially used in array index 
 calculations. In fact, i don't use the name 'length' for any variable in 
 D because of this.
 
 I wish, the implicit 'length' would be deprecated and then removed from D.
 
 Summay:
  - One thing/rule more to keep in mind
  - No benefit
  - It exists because it existed before we had $
  - Can cause problems
  - Restricts the use of the name 'length' for other variables.
 
 Removing 'length' would not break code in unexpected ways. It would 
 yield compile errors in every case and can be fixed by simple replacing 
 'length' to '$'.


For what it's worth, Andrei agrees with you.  It's one of the few points 
he made before he gave up on us cretins here in the newsgroups.  His 
argument was exactly the same.  It's a stealth keyword.

So there is a chance it will happen in D2.0x.

--bb

Robert Fraser <fraserofthenight gmail.com> writes:

Agreed. Actually, I don't think I've ever seen that feature used in any d code
I've seen, and it certainly wouldn't be hard to fix any errors it raised,
unless someone was actually relying on the shadowing aspect.

So, you got my vote.

Frank Benoit Wrote:

 Given this array:
 	int[] bar = new int[4];
 
 This is equivalent:
 	bar[ 1 .. length ] <->  bar[ 1 .. $ ]
 	bar[ length -1 ]   <->  bar[ $-1 ]
 
 'length' is implicitely declared within [ ].
 
 Since long time i think 'length' should be removed, because it can 
 conflict with a local 'length' variable. We have the special symbol $, 
 which does not have this problem.
 
 I think this matters in case of porting code. 'length' is an often used 
 variable name, especially in code portions acting with arrays. When 
 porting such stuff, all 'length' variables need to be renamed.
 
 But i see no benefit from this 'length'. It seems surprising for me. I 
 always use $. When i see foreign code using 'length', it looks wrong to me.
 
 Implicit 'length' does implicitely disallow the name 'length' for all 
 other integer like variables that are potentially used in array index 
 calculations. In fact, i don't use the name 'length' for any variable in 
 D because of this.
 
 I wish, the implicit 'length' would be deprecated and then removed from D.
 
 Summay:
   - One thing/rule more to keep in mind
   - No benefit
   - It exists because it existed before we had $
   - Can cause problems
   - Restricts the use of the name 'length' for other variables.
 
 Removing 'length' would not break code in unexpected ways. It would 
 yield compile errors in every case and can be fixed by simple replacing 
 'length' to '$'.

Pedro Ferreira <ask me.pt> writes:

Frank Benoit escreveu:
 Given this array:
     int[] bar = new int[4];
 
 This is equivalent:
     bar[ 1 .. length ] <->  bar[ 1 .. $ ]
     bar[ length -1 ]   <->  bar[ $-1 ]
 
 'length' is implicitely declared within [ ].
 
 Since long time i think 'length' should be removed, because it can 
 conflict with a local 'length' variable. We have the special symbol $, 
 which does not have this problem.
 
 I think this matters in case of porting code. 'length' is an often used 
 variable name, especially in code portions acting with arrays. When 
 porting such stuff, all 'length' variables need to be renamed.
 
 But i see no benefit from this 'length'. It seems surprising for me. I 
 always use $. When i see foreign code using 'length', it looks wrong to me.
 
 Implicit 'length' does implicitely disallow the name 'length' for all 
 other integer like variables that are potentially used in array index 
 calculations. In fact, i don't use the name 'length' for any variable in 
 D because of this.
 
 I wish, the implicit 'length' would be deprecated and then removed from D.
 
 Summay:
  - One thing/rule more to keep in mind
  - No benefit
  - It exists because it existed before we had $
  - Can cause problems
  - Restricts the use of the name 'length' for other variables.
 
 Removing 'length' would not break code in unexpected ways. It would 
 yield compile errors in every case and can be fixed by simple replacing 
 'length' to '$'.


You have my vote as well. Besides, writing array.$ is much quicker than
   array.length. Also, $ by in other places has no meaning other than
length (and tokens such as & and * have), which may make code clearer.
In my case, length is a common typo, as I am not english and frequently
end up writing 'lenght' instead.

Jesse Phillips <jessekphillips gmail.com> writes:

On Tue, 18 Mar 2008 14:48:54 +0000, Pedro Ferreira wrote:

 Frank Benoit escreveu:
 Given this array:
     int[] bar = new int[4];
 
 This is equivalent:
     bar[ 1 .. length ] <->  bar[ 1 .. $ ] bar[ length -1 ]   <->  bar[
     $-1 ]
 
 'length' is implicitely declared within [ ].
 
 Since long time i think 'length' should be removed, because it can
 conflict with a local 'length' variable. We have the special symbol $,
 which does not have this problem.
 
 I think this matters in case of porting code. 'length' is an often used
 variable name, especially in code portions acting with arrays. When
 porting such stuff, all 'length' variables need to be renamed.
 
 But i see no benefit from this 'length'. It seems surprising for me. I
 always use $. When i see foreign code using 'length', it looks wrong to
 me.
 
 Implicit 'length' does implicitely disallow the name 'length' for all
 other integer like variables that are potentially used in array index
 calculations. In fact, i don't use the name 'length' for any variable
 in D because of this.
 
 I wish, the implicit 'length' would be deprecated and then removed from
 D.
 
 Summay:
  - One thing/rule more to keep in mind - No benefit
  - It exists because it existed before we had $ - Can cause problems
  - Restricts the use of the name 'length' for other variables.
 
 Removing 'length' would not break code in unexpected ways. It would
 yield compile errors in every case and can be fixed by simple replacing
 'length' to '$'.


 You have my vote as well. Besides, writing array.$ is much quicker than
    array.length. Also, $ by in other places has no meaning other than
 length (and tokens such as & and * have), which may make code clearer.
 In my case, length is a common typo, as I am not english and frequently
 end up writing 'lenght' instead.


I don't know if they were interested in getting rid of array.length for 
array.$, just the use in []. I agree with removing it from within [], but 
as for it array.$ maybe we would have both?

Frank Benoit <keinfarbton googlemail.com> writes:

Jesse Phillips schrieb:
 On Tue, 18 Mar 2008 14:48:54 +0000, Pedro Ferreira wrote:
 You have my vote as well. Besides, writing array.$ is much quicker than
    array.length. Also, $ by in other places has no meaning other than
 length (and tokens such as & and * have), which may make code clearer.
 In my case, length is a common typo, as I am not english and frequently
 end up writing 'lenght' instead.


 I don't know if they were interested in getting rid of array.length for 
 array.$, just the use in []. I agree with removing it from within [], but 
 as for it array.$ maybe we would have both?


My original posting was meant only to remove it from within [].
I am ok with array.length and i personally don't like array.$