Add Iterable.range, List.range and int.to.

Add Iterable.range, List.range and int.to.

BUG= http://dartbug.com/20835

[Lasse Reichstein Nielsen, 2014-09-09 09:16:45]

lrn@google.com changed reviewers:
+ floitsch@google.com, sgjesse@google.com

[Lasse Reichstein Nielsen, 2014-09-09 09:16:45]

Comments on API, please.

I went with a static method instead of a constructor, because the type variable
is always <int>.

Should it be num instead of int? If so, should it detect that all arguments are
integers and create an Iterable<int> instead of Iterable<num>?
Should it be even more general, and work for any type that has suitable
operations (+/</unary- - and unary minus is only because I made step always
positive)?

[floitsch, 2014-09-09 09:37:14]

DBC.

https://codereview.chromium.org/551063003/diff/1/sdk/lib/core/iterable.dart
File sdk/lib/core/iterable.dart (right):

https://codereview.chromium.org/551063003/diff/1/sdk/lib/core/iterable.dart#n...
sdk/lib/core/iterable.dart:61: * or overshooting `to`. If it hits `to` the `to`
value is included,
Strongly oppose.
We have a getRange in this class that has different semantics.

[floitsch, 2014-09-09 09:38:30]

I don't think that we should add these methods.
We discussed them at length a few months ago and decided that neither semantics
(include or exclude the end-argument) is overwhelmingly "winning", and that it
would be way too easy to misread code that was using these methods.

[Søren Gjesse, 2014-09-09 09:45:54]

On 2014/09/09 09:38:30, floitsch wrote:
> I don't think that we should add these methods.
> We discussed them at length a few months ago and decided that neither
semantics
> (include or exclude the end-argument) is overwhelmingly "winning", and that it
> would be way too easy to misread code that was using these methods.

Couldn't we fit the generation of integer lists into the collection package?

[Lasse Reichstein Nielsen, 2014-09-09 09:48:17]

> Couldn't we fit the generation of integer lists into the collection package?

It's already in quiver, so no need for that. The real point here is the
shorthand 2.to(5), which is on int.
The two other methods are just parallel operations - the real implementation,
and a shorthand for createRange().toList().

(And I think the end should be included because it is not an index, it is a
value. We only generally exclude end indices).