www.digitalmars.com         C & C++   DMDScript  

D - Slicing notation

reply "Robert Medeiros" <robert.medeiros utoronto.ca> writes:
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
Jan 18 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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

 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

 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

Jan 19 2003
next sibling parent "Robert Medeiros" <robert.medeiros utoronto.ca> writes:
 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
Jan 19 2003
prev sibling parent reply Paul Conway <Paul_member pathlink.com> writes:
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
Jan 19 2003
parent reply "Robert Medeiros" <robert.medeiros utoronto.ca> writes:
Hi Paul,

 When you specify a range as [i..j), your j value may have to be one higher

 the highest legitimate value that a variable of its type can take. For

 for the range [0..255] you would have to specify [0..256] where 256 might

 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
Jan 20 2003
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
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!
Jan 21 2003
parent Burton Radons <loth users.sourceforge.net> writes:
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.
Jan 21 2003