Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
January 19, 2003 Slicing notation | ||||
---|---|---|---|---|
| ||||
Hi, I'm brand new to D (having heard about it via the recent Slashdot article) and am very impressed with the language. I look forward to seeing how it develops, using it, and possibly contributing. A minor suggestion: the array slicing notation might be more intuitive if it were asymmetric, i.e. the range [x .. y] is "[x,y)" in set notation so it seems that it might be a good idea to make the notation itself reflect this fact, e.g. [x..y), [x:.y], [x;..y] etc. IMO this enhances program readability and can help combat off-by-one errors. Just a thought. Rob |
January 19, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Medeiros | This has been suggested many times already. It's very difficult to parse properly, was the decision, I think. Sean "Robert Medeiros" <robert.medeiros@utoronto.ca> wrote in message news:b0dcgh$2ber$1@digitaldaemon.com... > Hi, > > I'm brand new to D (having heard about it via the recent Slashdot article) and am very impressed with the language. I look forward to seeing how it develops, using it, and possibly contributing. > > A minor suggestion: the array slicing notation might be more intuitive if it > were asymmetric, i.e. the range [x .. y] is "[x,y)" in set notation so it seems that it might be a good idea to make the notation itself reflect this > fact, e.g. [x..y), [x:.y], [x;..y] etc. IMO this enhances program readability and can help combat off-by-one errors. > > Just a thought. > > Rob |
January 19, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | > This has been suggested many times already. It's very difficult to parse properly, was the decision, I think. Thanks. Ironically, I spent a fair number of hours browsing the newsgroup archives in an attempt to find a feature I could suggest that hadn't already been requested... Newsgroup: 1, Rob: 0. :) Maybe this is a novel: A rewrite of dmdalpha as a front-end for the SUIF project, located at http://suif.stanford.edu/suif/suif2/index.html. The principal benefit is the ease with which optimizations written by others can be applied to D programs. Rob |
January 19, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | I once browsed through what I thought was a dumb book on robust programming, written by someone at Microsoft. A lot of what it suggested was stuff that is pretty obvious to a regular C or C++ programmer. However there was this: When you specify a range as [i..j), your j value may have to be one higher than the highest legitimate value that a variable of its type can take. For example for the range [0..255] you would have to specify [0..256] where 256 might be illegal if the index is a 1-byte char. The compile might not promote the char value 255+1 to an unsigned short, so it might wrap it round to 0, and then you are in trouble. Or you might have an enum with valid values a,b,c,d as 0..3 and you would need to specify [a..d+1) to get the whole range. Yet d+1 would be illegal. Similarly if you want [0xFFFFFE00..0xFFFFFFFF] then you would need to specify [0xFFFFFE00..0x100000000) and your compiler might get upset or generate 0. I don't know if these problems can occur in D, under any circumstances. But the idea of explicitly specifying a value that might be 1 greater than the maximum permitted surely is a bit worrisome? "A mechanism of world inter-communication will be devised, embracing the whole planet, freed from national hindrances and restrictions, and functioning with marvellous swiftness...." -- Shoghi Effendi -- The Unfoldment of World Civilisation -- 11 Mar 1936 |
January 20, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Conway | Hi Paul, > When you specify a range as [i..j), your j value may have to be one higher than > the highest legitimate value that a variable of its type can take. For example > for the range [0..255] you would have to specify [0..256] where 256 might be > illegal if the index is a 1-byte char. http://www.python.org/doc/current/ref/slicings.html I think python slicing is instructive; the notation [x:] with the second index absent means to slice until the end of the "array", be it list or string, etc. Given the properties of D arrays (the size of the array is stored) I think something similar might work with them as well, but some more thought on the matter is definitely warranted -- or not, as the case may be. :) Rob |
January 21, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Medeiros | Robert Medeiros wrote:
> Hi Paul,
>
>
>>When you specify a range as [i..j), your j value may have to be one higher
>
> than
>
>>the highest legitimate value that a variable of its type can take. For
>
> example
>
>>for the range [0..255] you would have to specify [0..256] where 256 might
>
> be
>
>>illegal if the index is a 1-byte char.
>
>
> http://www.python.org/doc/current/ref/slicings.html
>
> I think python slicing is instructive; the notation [x:] with the second
> index absent means to slice until the end of the "array", be it list or
> string, etc. Given the properties of D arrays (the size of the array is
> stored) I think something similar might work with them as well, but some
> more thought on the matter is definitely warranted -- or not, as the case
> may be. :)
I think that
array[x..]
already works!
|
January 21, 2003 Re: Slicing notation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russell Lewis | Russell Lewis wrote:
> Robert Medeiros wrote:
>> I think python slicing is instructive; the notation [x:] with the second
>> index absent means to slice until the end of the "array", be it list or
>> string, etc. Given the properties of D arrays (the size of the array is
>> stored) I think something similar might work with them as well, but some
>> more thought on the matter is definitely warranted -- or not, as the case
>> may be. :)
>
> I think that
> array[x..]
> already works!
DLI only.
|
Copyright © 1999-2021 by the D Language Foundation