For loop modifier blocks

[bujiraso]

Actually that’s great! Thanks!

[drXor]

I just checked the grammar- unfortunately, neither then or between can be mere contextual keywords, since this compiles today:

struct then {}
for _ in 0..1 {} then {}

We have two options: use existing reserved keywords, wait until another round of keyword additions arrives, or something horrible like

for _ in 0..1  {

} then do {

}

[Nokel81]

To be fair I don’t think that last solution is that horrible but I would agree that it is sub optimal. I don’t think that something like this is worthy to wait until we can reserve new keywords though

[josh]

This makes what you’re looking for much clearer.

However, I feel like these are sufficiently uncomon loop constructs that it’d make sense to start out implementing them as macros and see if they end up getting widely used. I don’t know of any precedent for these other than Python’s else on for loops.

Do you know of any precedent for between?

[Nokel81]

Sure I can look into making macros for these.

For between the precedent mainly revolves around rust’s general inclination to promote the use of iterators. When using c style for loops you can do a temporary increment and check yourself.

Therefore it is possible with those loops but prone to maintainence fatigue since any change to the loop check how has to be checked twice.

However, with iterator loops this is almost impossible. The for-loop example I gave above. You would have to produce a separate variable for the current index and then check that verses the length. But that does not translate to non-ordered structs very well.

[Nokel81]

I figured that if you were to have Python style else we might as well have the opposite.

[newpavlov]

Take a look at this proposal, which is somewhat alternative to that you propose:

[Pre-RFC]: Generator integration with for loops

Motivation Although Generator was initially introduced with async story in mind, it can be also used for enhancing core for loop functionality. Integration of Generator with for loops looks quite natural: for value in generator { // .. } Here we iterate over yielded values and discard return value of the generator. Introduction of this feature will also prevent a lot of confusion for people coming from Python, as syntax of for loops and generators are quite close, thus it will be natural …

[Nokel81]

Thank you for linking that proposal, it is indeed a somewhat alternative to what I am proposing. I think that the generator argument is a very strong one for these sorts of blocks since it is impossible in a for loop to know if you are in the last iteration.

[H2CO3]

You would have to produce a separate variable for the current index and then check that verses the length. But that does not translate to non-ordered structs very well.

What do you mean by a “non-ordered struct”? And how would something not work with them? Do you mean iterators with no known length/iteration count? How do you expect such iterators to be able to tell whether they are at the last or penultimate iteration with the help of any sort of syntactic sugar? That would require predicting their future state which is just as impossible with between blocks as without them.

[Nokel81]

I mean structs that don’t have a definite order, a vector does since it is like an array but a hash map does not necessarily have a well defined order that you can test given the current item. Of course you could also get the “index” and the count within the map but I am trying to avoid having to do that because it is messy because that piece of information is not really pertinent to the computation.

[mbrubeck]

between can be implemented to run before each iteration except the first. Then you just need a single boolean flag that gets set after the first iteration.

[Nokel81]

Yes that is very true, but it leads to many more variables concerned strictly about control flow and not data, in a sense flag variables. Which is not often good software design, that is why I am proposing block level scoped control flow.

[H2CO3]

Ah, so you mean an unordered data structure, fair enough. I still don’t think avoiding .enumerate() and index < the_hash_map.len() - 1 warrants complicating the core language, though. It’s an uncommon enough case to be served well enough by this idiom.

[Nokel81]

I guess it is uncommon, however, I feel that languages should still be expressive and if a language can reduce the amount that flag variables are relied upon then the resulting programs will be easier to understand

[scottmcm]

if a language can reduce the amount that flag variables are relied upon

Avoiding pervasive use of flag variables is certainly a good thing, but it doesn’t necessarily need a language change. For example, you can use Itertools::with_position to conveniently do different things in different positions while iterating, or Itertools::intersperse to add things between items, or …

[Nokel81]

Could it be a contextual keyword if it required the else.

I mean the following would be allowed:

for i in 0..1 {
    ...
}

for i in 0..1 {
    ...
} else {
    ...
}

for i in 0..1 {
    ...
} then {
    ...
} else {
    ...
}

but not:

for i in 0..1 {
    ...
} then {
    ...
}

This would be able to be done until the next round of keyword registration comes around.

This sort of makes sense since if you want to do something special when a loop normally exits but doesn’t break it is probably also when you want to do something if it break.

---

Or we could just forgo the whole thing and use for then and for else

[Pazzaz]

I tried implementing this as a macro. (link) This can then be used like this:

fn main() {
    let mut list = String::new();
    custom_loop!(
        for a in 0..11; { // `;` needed because of macro limitation
            list.push_str(&format!("{}", a));
        } between {
            list.push_str(", ");
        } then {
            list.push_str(" END")
        }
    );
    println!("{}", list); // "0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 END"
}

And combining all features

fn main() {
    let mut list = String::new();
    custom_loop!(
        for a in 0..11; {
            if a > 5 {
                break
            }
            list.push_str(&format!("{}", a));
        } between {
            list.push_str(", ");
        } then {
            list.push_str(" END")
        } else {
            list.push_str("EARLYEND")
        }
    );
    println!("{}", list); // "0, 1, 2, 3, 4, 5, EARLYEND"
}

and that expands to this:

fn main() {
    let mut list = String::new();
    {
        let mut _normal = true;
        let mut iter = IntoIterator::into_iter(0..11);
        let a = iter.next();
        if a.is_some() {
            _normal = false;
            let mut a = a.unwrap();
            loop {
                if a > 5 {
                    break
                }
                list.push_str(&format!("{}", a));
                a = match iter.next() {
                    Some(x) => {
                        list.push_str(", ");
                        x
                    }
                    None => {
                        _normal = true;
                        break
                    }
                };
            }
        }
        if _normal {
            list.push_str("END")
        } else {
            list.push_str("EARLYEND")
        }
    }
    println!("{}", list);
}

Should be useful if someone wants to try out this feature.

[gbutler]

Is there a particular reason that the “then” and “else” take an expression whereas the “between” block takes a statement? If so, how is that enforced? Or is it?

[Pazzaz]

No, the missing semicolons were typos. The macro itself operates on blocks and doesn’t care about the content as long as they return (). This matches the behavior of regular for loops.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.