## Feature #8842

### Integer#[] with range

Status: | Assigned | ||
---|---|---|---|

Priority: | Normal | ||

Assignee: | Yusuke Endoh |

**Description**

=begin

I propose to extend Integer#[] accepting a range.

0b01001101[2, 4] == 0b0011 0bHGFEDCBA[2, 4] == 0bFEDC

== Use case

I believe that everyone has written a code like this:

if (n >> 2) & 0xf == 0x3 ... end

because this is a very common idiom in C.

But it is less readable, writable, extendable and optimizable.

if n[2, 4] == 0x3 ... end

is much better in the all aspects.

== Corner cases

The current Integer# handle an integer as "a bit array with infinity length";

it returns 0 for any negative index and an (extended) sign bit for any index greater than MSB.

We also can use this standard to define the spec for a range argument.

For example:

15[-1, 42] #=> 30 (equivalent to (15 << 1) && (2 ** 42 - 1)) 15[3, 42] #=> 1 (equivalent to (15 >> 3) && (2 ** 42 - 1)) 15[3..Float::INFINITY] #=> 1 (equivalent to 15 >> 3) 15[-3..Float::INFINITY] #=> 2 (equivalent to 1 << 3) -1[0..Float::INFINITY] #=> -1 -1[1..Float::INFINITY] #=> -1 -1[-1..Float::INFINITY] #=> -2 1[-Float::INFINITY..0] #=> failed to allocate memory 2[-Float::INFINITY..0] #=> 0

Only tricky case that I thought of is a range (beg..end) whose "end" is smaller than "beg".

I think it should be handled as (beg..Float::INFINITY).

15[-3..-4] #=> 2 (equivalent to 1 << 3) -1[0..-1] #=> -1 -1[0..-2] #=> -1

What do you think?

=end

### History

#### #1 Updated by Yusuke Endoh about 2 years ago

**File**integer-with-range.pdf added

#### #2 Updated by Yusuke Endoh about 2 years ago

**Tracker**changed from*Bug*to*Feature*

#### #3 Updated by Yukihiro Matsumoto about 2 years ago

**Assignee**changed from*Yukihiro Matsumoto*to*Yusuke Endoh*

Accepted.

Matz.

#### #4 Updated by Anonymous about 2 years ago

I take it that the use of '&&' operator in the first 2 corner cases is a typo. But, pardon my ignorance,

in the 4th corner case, why 15[-3..Float::INFINITY] #=> 2 (equivalent to 1 << 3)?

1 << 3 is 8, and even if I assume a typo, 15 << 3 is 120. Is there something I misunderstood?

#### #5 Updated by Yusuke Endoh about 2 years ago

**Target version**changed from*next minor*to*2.1.0*

I take it that the use of '&&' operator in the first 2 corner cases is a typo.

Yes, sorry.

in the 4th corner case, why 15[-3..Float::INFINITY] #=> 2 (equivalent to 1 << 3)?

1 << 3 is 8, and even if I assume a typo, 15 << 3 is 120. Is there something I misunderstood?

No, you are right.

15[-3..Float::INFINITY] #=> 120 (equivalent to 15 << 3)

is correct.

Also, the attached slide has a bug: n[2..6] should be n[2..5] or n[2...6].

I'm sorry. Haste is from the devil. I'll make a patch more carefully.

--

Yusuke Endoh mame@tsg.ne.jp

#### #6 Updated by Hiroshi SHIBATA almost 2 years ago

**Target version**changed from*2.1.0*to*current: 2.2.0*