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

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

> 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

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

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

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!

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.