www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Removal of implicit variable "length"

reply Bradley Smith <digitalmars-com baysmith.com> writes:
In a posting from about a year ago 
(http://www.digitalmars.com/d/archives/digitalmars/D/learn/842.html), 
the implicit variable "length" was scheduled for potential
deprecation.

Is it going to be removed? If so, when?

I see this as a significant flaw in the D language. For example, what 
does the following code do?

   import std.stdio;  // for writefln

   void main() {
     static int[4] foo = [ 0, 1, 2, 3 ];
     int[] bar;
     int length = 2;
     bar = foo[0 .. length];
     writefln("bar = %s", bar);
   }


What is does the program print?
   A. bar = [0,1,2,3]
   B. bar = [0,1]

I would guess that most programmers unfamilar with D would answer "B". 
However, "A" is the correct answer. It certainly has been a lesson I've 
had to learn the hard way.

Besides, is "foo[0 .. length]" really better than "foo[0 .. 
foo.length]"? The first is slightly more convenient but the second is 
more explicit and readable.

Thanks,
   Bradley
Jun 06 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bradley Smith" <digitalmars-com baysmith.com> wrote in message 
news:e64tgp$1gvu$1 digitaldaemon.com...


 I would guess that most programmers unfamilar with D would answer "B". 
 However, "A" is the correct answer. It certainly has been a lesson I've 
 had to learn the hard way.


Have you heard of $ ?

bar = foo[0 .. $];

Additionally, try turning on warnings for your original code, and you'll 
notice you get one.

It probably is time to deprecate length inside array braces.


 Besides, is "foo[0 .. length]" really better than "foo[0 .. foo.length]"? 
 The first is slightly more convenient but the second is more explicit and 
 readable.


How about things like

int[] x = ALongClassName.AnotherClassName.aNonTrivialOperation()[1 .. $];

It's certainly nice to have a shortcut in cases like this, when typing out 
the original expression is not only prohibitively long, but could possibly 
waste performance re-evaluating the reference to the array.
Jun 06 2006
parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
Jarrett Billingsley wrote:

 Have you heard of $ ?
 
 bar = foo[0 .. $];


I did notice the mention of "$" in the old newsgroup thread. However, I 
can't find any official documentation on it.



 Additionally, try turning on warnings for your original code, and you'll 
 notice you get one.


Thanks for pointing out the warnings. I wasn't aware of that warning. 
Because libraries often cause many warnings, I don't regularly have 
warning turned on.



 How about things like
 
 int[] x = ALongClassName.AnotherClassName.aNonTrivialOperation()[1 .. $];
 
 It's certainly nice to have a shortcut in cases like this, when typing out 
 the original expression is not only prohibitively long, but could possibly 
 waste performance re-evaluating the reference to the array. 
 


Why not the following?

int[] ref = ALongClassName.AnotherClassName.aNonTrivialOperation();
int[] x = ref[1 .. ref.length];

Or perhaps?

int[] x = ALongClassName.AnotherClassName.aNonTrivialOperation();
x = x[1 .. x.length];

Will use of "$" be faster than using a local reference?

Unless there is a reason not to create a local reference to an array, I 
don't think either "length" or "$" are necessary. At least "$" shouldn't 
cause programming errors, but it does make the language more complex.

Thanks,
   Bradley
Jun 06 2006
next sibling parent kris <foo bar.com> writes:
Bradley Smith wrote:

 Jarrett Billingsley wrote:
 

 Have you heard of $ ?

 bar = foo[0 .. $];


 
 
 I did notice the mention of "$" in the old newsgroup thread. However, I 
 can't find any official documentation on it.
 
 

 Additionally, try turning on warnings for your original code, and 
 you'll notice you get one.


 
 
 Thanks for pointing out the warnings. I wasn't aware of that warning. 
 Because libraries often cause many warnings, I don't regularly have 
 warning turned on.
 
 

 How about things like

 int[] x = ALongClassName.AnotherClassName.aNonTrivialOperation()[1 .. $];

 It's certainly nice to have a shortcut in cases like this, when typing 
 out the original expression is not only prohibitively long, but could 
 possibly waste performance re-evaluating the reference to the array.


 
 
 Why not the following?
 
 int[] ref = ALongClassName.AnotherClassName.aNonTrivialOperation();
 int[] x = ref[1 .. ref.length];
 
 Or perhaps?
 
 int[] x = ALongClassName.AnotherClassName.aNonTrivialOperation();
 x = x[1 .. x.length];


The original reason, IIRC, was with regard to using arrays + templates, 
where it's not always so easy to leverage temps. However, that orignal 
change brought us the maligned x[0..length] and its special cases. Took 
a long time (a year, perhaps?) and many frustrating battles to get that 
issue rectified, and the result was that sole '$' token


 
 Will use of "$" be faster than using a local reference?
 
 Unless there is a reason not to create a local reference to an array, I 
 don't think either "length" or "$" are necessary. At least "$" shouldn't 
 cause programming errors, but it does make the language more complex.


It was argued at the time that $len should be used, so that the $ prefix 
could thus signify meta-notions in general ($file, $line, $time, etc). 
In fact, it was perhaps the only time I recall a general concensus on 
anything ;)

But, that notion went nowhere as you can see. We just move on
Jun 06 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bradley Smith" <digitalmars-com baysmith.com> wrote in message 
news:e658a2$1r3s$1 digitaldaemon.com...


 Will use of "$" be faster than using a local reference?

 Unless there is a reason not to create a local reference to an array, I 
 don't think either "length" or "$" are necessary. At least "$" shouldn't 
 cause programming errors, but it does make the language more complex.


As Brad said, sometimes you don't have the luxury of using temporaries, such 
as with templates.

I doubt $ is any faster, performancewise, but it's certainly faster when 
typing.  I also wouldn't say that $ makes the language more complex - it 
adds a small amount of complexity, yes, but you also have to realize that 
it's only used in slice expressions, which in themselves are something that 
add complexity to the language!  I just think of $ as a feature of slice 
expressions.
Jun 06 2006