feat($parse): Adds range operators

[lgalfaso]

Adds the operators '..' and '...' that work as range operators. These new operators are only valid within an array declaration and allows the array to be declared as a range. E.g.

<div ng-repeat="index in [1...pages.length]">{{index}}</div>

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#8210)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[caitp]

It looks like this will return a new array every time the expression is evaluated (I guess we were doing that already)... is that what we want? (serious question, I see pros/cons for both ways)

[lgalfaso]

I put this up to start the discussion if this is something what we want

It looks like this will return a new array every time the expression is evaluated (I guess we were doing that already)... is that what we want? (serious question, I see pros/cons for both ways)

Even when we are already creating a new instance of the array every single time, it should be possible to cache the array in case the right hand side and left hand side are constants.
It still does not support characters as values. E.g. ['a'...'z']

[PatrickJS]

+1

[lgalfaso]

this is not going to happen in 1.x, so there is no need to keep this open

[pkozlowski-opensource]

@lgalfaso just out of curiosity - was the implementation too big / difficult / generating too many corner cases or is it about perf considerations?

I won't be crying over this one, but it was kind of neat feature so was wondering what were the pbs with it.

[lgalfaso]

@pkozlowski-opensource just not enough traction to make it into the core (specially when you can get a more flexible approach with filter)

[pkozlowski-opensource]

@lgalfaso yeh, makes sense.