Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
June 06, 2006 Removal of implicit variable "length" | ||||
---|---|---|---|---|
| ||||
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 |
June 07, 2006 Re: Removal of implicit variable "length" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bradley Smith | "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. |
June 07, 2006 Re: Removal of implicit variable "length" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 |
June 07, 2006 Re: Removal of implicit variable "length" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bradley Smith | 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 |
June 07, 2006 Re: Removal of implicit variable "length" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bradley Smith | "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. |
Copyright © 1999-2021 by the D Language Foundation