Extend iterators notation

#1

Iterators should be widely used in rust, but currently their notation is quite limiting. Below are three points that I would suggest to consider for extension of the iterators notation.

The first point is the ability to specify the type of the iterator. I am not sure what would be the best notation for this, probably something like:

(1..)u64.step_by(5)

The second point is the ability to operate on floats, for instance:

(1..-100)f64.step_by(-2.5)

The last point is regarding the exclusive upper bound. I agree this is convenient in some contests, because for instance 0..10 is similar to the typical C statement for (i = 0; i < 10; i++). However it can be source of bugs in other contests, for instance numerical computation. For this I would suggest to add the notation 0:10 with inclusive upper bound, which is used by MATLAB and many other numerical computing languages.

Why strings and vectors are treated differently? (syntactically)
#2

This all works except for the f64 step but it requires the nightlies:

#![feature(step_by)]

fn main() {
    for i in (0i32..).step_by(3).take(10) {
        println!("Step forward: {}", i);
    }
    for i in (0i32..).step_by(-3).take(10) {
        println!("Step backward: {}", i);
    }
}

Including notation for inclusive ranges has been discussed extensively. Some of the candidates are ... and ..=. The positives are you can write inclusive ranges. The negatives are you have to pay attention what kind of range you are using. The difficulty varies with notation. People have different opinions about whether it would be problematic.

An alternative is to use (0i32..10).inclusive() but it doesn’t seem to be implemented. I wouldn’t be surprised if this gets implemented because none of the other options are jumping out as solid winners. This would at least be extremely obvious which has some benefits.

#3

Thanks for referencing me to that thread. The Mesa notation is the best one IMO, but if the parser cannot manage unbalanced brackets I support @tommit notation:
a...b for [a, b]
a..<b for [a, b)
a>..b for (a, b]
a>.<b for (a, b)