## D - Newbie.. Slicing

• Zev Griner (10/10) Feb 02 2003 Can someone point me to a discussion that explains why slicing [m..n] wa...
• Daniel Yokomiso (33/43) Feb 02 2003 to be
• Antti Sykari (14/28) Feb 02 2003 True :) A very religious issue.
• Ilya Minkov (3/64) Feb 04 2003 If slicing is made inclusive (Delphi!), you could use [..] to express an...
• Ilya Minkov (3/86) Feb 04 2003 Oh, sorry. Now i was reading more carefully. Sure, D makes it the right
```Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Here I am looking at two numbers and I am supposed to remember that 'n' is to be
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0 <= i <
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner
```
Feb 02 2003
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
```"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...
Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Here I am looking at two numbers and I am supposed to remember that 'n' is

to be
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

<= i <
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner

Hi,

The discussion about slices and ranges never dies around here ;-)
There's are a couple of simple answers to this. First is that D has its
origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
said, so in D a code to manually slice an array would use this notation. If
the notation for slices were different people would always remember that
slicing is inclusive in both ends, while common array loop is
inclusive/exclusive. But the most important reason is that using this
notation we can express empty slices without trouble. Writing "someArray[0
.. 0]" is always right, giving a empty array. When you write functions that
slice arrays you usually have to deal with this problem, and if the default
slicing is inclusive/exclusive you don't need to write tests to check for
the empty slice case. The only language I know that use both ends inclusive
notation and is useable is Icon, but their array indices are different (they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).
I agree that some people will be surprised by this, but they'll get used
to this start/after end definition. If I defined this, I would prefer a
start/length notation instead, because most of the time I write "someArray[n
.. n + x]" instead of "someArray[n .. m]".

Best regards,
Daniel Yokomiso.

"Being right too soon is socially unacceptable."
- Robert A. Heinlein

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
```
Feb 02 2003
Antti Sykari <jsykari gamma.hut.fi> writes:
```"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...
Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

The discussion about slices and ranges never dies around here ;-)

True :)  A very religious issue.

It seems that the notation x..y will cause bugs either way, if half of
the people assume it means inclusive, and half of the people assume
it's exclusive.

There's are a couple of simple answers to this. First is that D
has its origins on C, and in C every loop on arrays goes from 0 <= i
< n, as you said, so in D a code to manually slice an array would
use this notation.

why not ditch the C(++) practice and use 0 <= i <= n, because, after
all, that would be symmetric? Low-level efficiency concerns?

the empty slice case. The only language I know that use both ends inclusive
notation and is useable is Icon, but their array indices are different (they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).

I don't know what you consider a *useable* language :) However, of the
languages of I know, perl, zsh and ruby have x..y in the meaning of "x
through y inclusive"

Non-inclusive ranges are needed, too, so ruby has solved the problem
by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

-Antti
```
Feb 02 2003
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
```"Antti Sykari" <jsykari gamma.hut.fi> escreveu na mensagem
news:86bs1tj3vm.fsf hoastest1-8c.hoasnet.inet.fi...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...
Can someone point me to a discussion that explains why slicing [m..n]

was
defined as m <= i < n as opposed m <= i <= n?

The discussion about slices and ranges never dies around here ;-)

True :)  A very religious issue.

It seems that the notation x..y will cause bugs either way, if half of
the people assume it means inclusive, and half of the people assume
it's exclusive.

There's are a couple of simple answers to this. First is that D
has its origins on C, and in C every loop on arrays goes from 0 <= i
< n, as you said, so in D a code to manually slice an array would
use this notation.

why not ditch the C(++) practice and use 0 <= i <= n, because, after
all, that would be symmetric? Low-level efficiency concerns?

the empty slice case. The only language I know that use both ends

inclusive
notation and is useable is Icon, but their array indices are different

(they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).

I don't know what you consider a *useable* language :) However, of the
languages of I know, perl, zsh and ruby have x..y in the meaning of "x
through y inclusive"

The range notation for slicing isn't perfect, I think that using ":" a
la Python would be better. But the rationale for the idiom is clear, and if
we need one IMHO this is the best. Ruby has three forms of slicing IIRC
"someArray[start, count]", "someArray[start .. end]" and "someArray[start
... afterEnd]", so they don't have this problem, but also don't have an
unique notation.

Non-inclusive ranges are needed, too, so ruby has solved the problem
by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

-Antti

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
```
Feb 03 2003
```On Mon, 03 Feb 2003 08:05:17 +0200, Antti Sykari <jsykari gamma.hut.fi>
wrote:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...
Can someone point me to a discussion that explains why slicing [m..n]
was
defined as m <= i < n as opposed m <= i <= n?

The discussion about slices and ranges never dies around here ;-)

True :)  A very religious issue.

It seems that the notation x..y will cause bugs either way, if half of
the people assume it means inclusive, and half of the people assume
it's exclusive.

It really is too hard, isn't it.

If a language has inclusive slices, to get a non-inclusive you do...
[x..y-1]

If a language has non-inclusive slices, to get an inclusive you do ...
[x..y+1]

There's are a couple of simple answers to this. First is that D
has its origins on C, and in C every loop on arrays goes from 0 <= i
< n, as you said, so in D a code to manually slice an array would
use this notation.

why not ditch the C(++) practice and use 0 <= i <= n, because, after
all, that would be symmetric? Low-level efficiency concerns?

Or even 1 <= i <= n, if you want to get away from techo-thinking,

the empty slice case. The only language I know that use both ends
inclusive
notation and is useable is Icon, but their array indices are different
(they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).

hmmm... "usable" ?
I don't know what you consider a *useable* language :) However, of the
languages of I know, perl, zsh and ruby have x..y in the meaning of "x
through y inclusive"

Non-inclusive ranges are needed, too, so ruby has solved the problem
by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

And of course, no-one would accidently misread or miscode an extra '.',
would they?

--
xyzzy
```
Feb 04 2003
Ilya Minkov <midiclub 8ung.at> writes:
```If slicing is made inclusive (Delphi!), you could use [..] to express an
empty slice ;)

Daniel Yokomiso wrote:
"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...

Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Here I am looking at two numbers and I am supposed to remember that 'n' is

to be

ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

<= i <

n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner

Hi,

The discussion about slices and ranges never dies around here ;-)
There's are a couple of simple answers to this. First is that D has its
origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
said, so in D a code to manually slice an array would use this notation. If
the notation for slices were different people would always remember that
slicing is inclusive in both ends, while common array loop is
inclusive/exclusive. But the most important reason is that using this
notation we can express empty slices without trouble. Writing "someArray[0
.. 0]" is always right, giving a empty array. When you write functions that
slice arrays you usually have to deal with this problem, and if the default
slicing is inclusive/exclusive you don't need to write tests to check for
the empty slice case. The only language I know that use both ends inclusive
notation and is useable is Icon, but their array indices are different (they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).
I agree that some people will be surprised by this, but they'll get used
to this start/after end definition. If I defined this, I would prefer a
start/length notation instead, because most of the time I write "someArray[n
.. n + x]" instead of "someArray[n .. m]".

Best regards,
Daniel Yokomiso.

"Being right too soon is socially unacceptable."
- Robert A. Heinlein

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

```
Feb 04 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Oh, sorry. Now i was reading more carefully. Sure, D makes it the right
way, i beleve...

Ilya Minkov wrote:
If slicing is made inclusive (Delphi!), you could use [..] to express an
empty slice ;)

Daniel Yokomiso wrote:

"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp\$r4j\$1 digitaldaemon.com...

Can someone point me to a discussion that explains why slicing [m..n]
was
defined as m <= i < n as opposed m <= i <= n?

Here I am looking at two numbers and I am supposed to remember that
'n' is

to be

ignored. It's bad enough that C arrays, defined as [n], are accessed
as 0

<= i <

n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements
within the
boundaries, inclusively.

Thanx
Zev Griner

Hi,

The discussion about slices and ranges never dies around here ;-)
There's are a couple of simple answers to this. First is that D
has its
origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
said, so in D a code to manually slice an array would use this
notation. If
the notation for slices were different people would always remember that
slicing is inclusive in both ends, while common array loop is
inclusive/exclusive. But the most important reason is that using this
notation we can express empty slices without trouble. Writing
"someArray[0
.. 0]" is always right, giving a empty array. When you write functions
that
slice arrays you usually have to deal with this problem, and if the
default
slicing is inclusive/exclusive you don't need to write tests to check for
the empty slice case. The only language I know that use both ends
inclusive
notation and is useable is Icon, but their array indices are different
(they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).
I agree that some people will be surprised by this, but they'll
get used
to this start/after end definition. If I defined this, I would prefer a
start/length notation instead, because most of the time I write
"someArray[n
.. n + x]" instead of "someArray[n .. m]".

Best regards,
Daniel Yokomiso.

"Being right too soon is socially unacceptable."
- Robert A. Heinlein

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

```
Feb 04 2003