Hi,

I think it would be nice to have lshift and rshift methods in Range class:

Range lshift(Int delta) { rshift(-delta) }

Range rshift(Int delta) { Range.make(start + delta, end + delta, exclusive) }

so we can write:

(0..<5) >> 4 //(4..<9)
(1..2) << 1 //(0..1)

Probably this is not very frequent operation, but when you need it, having such methods is better than, for example, add two more static methods in some utility class

I don't have a problem adding a method to shift ranges. Although I don't really want to do with operators - seems like a bit of operator overload abuse.

Is there anyone else who thinks this would be a useful method on Range?

I wouldn't want to see the operators here, these are very bitwise operators in my mind.

Not sure whether the methods are useful. The task feels rather like a list comprehension or closures.

The task feels rather like a list comprehension or closures.

Could you elaborate on this? I have absolutely no idea what you mean?

Truth be told plus and minus seem more at home that rshift, lshift. I know this is just C++ talking but when I see << or >> I think of Streams.

That you could use a list comprehension or a closure to perform the task of adding 4 to each element of a range.

AFAIK Fantom does not have a list comprehensions syntax, but as it's just sugar for mapping and filtering you probably mean something like this:

(0..<5).map |i->Int| { i + 4 }

This creates a list not a range and I don't see how it could.

++

Range shift(Int delta) { Range.make(start + delta, end + delta, exclusive) }

Would adding/subtracting an Int on Range have more sense?

From my perspective, operator overloading is out of the question here. I don't like using operators for obscure cases like this.

However, if there are multiple people who think this method would be useful then it probably belongs in the core Range class. So my two questions:

1. who thinks this method would be useful?
2. what is a good name, my two favs are shift or offset

I would lean more toward plus and minus than lshift and rshift, but I agree with brian that this would be supported better through a regular method than through operator overloading. +1 for sys::Range.offset or offsetBy

1..10.offsetBy(2)    // 2..12
10..<15.offsetBy(-5) // 5..<10

Hmm, the dot . binds to the range end literal rather than to the range, so my example would be:

(1..10).offsetBy(2)    // 2..12
(10..<15).offsetBy(-5) // 5..<10

Further evidence that we should not overload the plus / minus operators:

1..10 + 2 // 1..12
1..10 - 2 // 1..8

This is somewhat surprising though, I would expect the + to bind to the Range and not to the range end.

How is that proof? I mean, where are the examples from?

1..10 + 2 //3..12

seems as intuitive as your example.

Either way I agree. Best not to abuse the sugar in such ways.

+1 for offset(Int).

Renamed from Range.lshift proposal to Range.offset

Promoted to ticket #860 and assigned to brian

Ticket resolved in 1.0.48

Added new method to Range:

**
** Create a new range by adding offset to this range's
** start and end values.
**
** Example:
**   (3..5).offset(2)   =>  5..7
**   (3..<5).offset(-2) =>  1..<3
**
Range offset(Int offset)

changeset