Skip to content

Loop x times #2792

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pbbob opened this issue Oct 26, 2019 · 5 comments
Closed

Loop x times #2792

pbbob opened this issue Oct 26, 2019 · 5 comments
Labels
A-control-flow Proposals relating to control flow. A-expressions Term language related proposals & ideas A-syntax Syntax related proposals & ideas T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@pbbob
Copy link

pbbob commented Oct 26, 2019

It would be nice to be able to do this:

let count = 15;
loop count {
    println!("{}", count);
}

would loop 15 times.

@RustyYato
Copy link

Whats wrong with

for _ in 0..15 {
    println!("{}", count);
}

@pbbob
Copy link
Author

pbbob commented Oct 26, 2019

@KrishnaSannasi

Whats wrong with

for _ in 0..15 {
    println!("{}", count);
}

These have different semantic meanings. for _ in 0..15 is the same as for _ in 1234..1249. loop 15 makes it clear that it is just being repeated x times.

@RustyYato
Copy link

RustyYato commented Oct 26, 2019

Ok, how often do you actually need to repeat a thing a fixed number of times? I don't see the point of this extensions, especially when for _ in 0..$count { ... } does the job and is very clear. Keeping 0 as the lower bound and using _ to ignore the iterator items makes it clear that you want to do is loop a fixed number of times.

Is there precedence for this sort of loop in other languages? I can't think of any of the top of my head.

Extending loop to do this doesn't seem to be very productive, or add very much. In fact it detracts from the meaning of loop a bit. There is utility in knowing that loop implies some strange control flow (which can't be modeled by for or while). So, adding loop $count { ... }, while minor on it's own, does somewhat break this rule. (Although, I have seen other proposals to do exactly this, so there may be some merit to adding it)

What values can you put in $count? Any integer? Does it have to be compile time known? Can we use custom types in $count? If so, what trait controls the behavior?

Finally, there is the concern of how to handle break in this loop.

Right now, you can do this.

assert_eq!(1, loop { break 1 });

I would expect loop $count { break 1 } to be a compiler error, because the loop could end gracefully similarly to how for _ in 0..$count { break 1 } is an error.


Are there any parsing ambiguities with this? For example

loop { return } { }

could parse as

loop $count { } // where $count = { return 10 }

or

loop { return } // normal infinite loop that is terminated by a return
{ }             // unreachable block

@hadronized
Copy link
Contributor

for _ in 0 .. nb is pretty clear to me and already small enough. Furthermore, loop constructs have contracts:

  • for is often used for deterministic looping — i.e. when you know at most how many times you’ll iterate.
  • while is used to loop while a condition is held true, which is already different from the previous construct.
  • loop is used to loop without even knowing the condition and requires a break.

What you describe falls in the first family of constructs and I suggest you simply add macro for it or just an Iterator type, such as:

for _ in times(3) {
}

Or,

times(3, || {
});

@Centril Centril added A-control-flow Proposals relating to control flow. A-expressions Term language related proposals & ideas A-syntax Syntax related proposals & ideas T-lang Relevant to the language team, which will review and decide on the RFC. labels Oct 26, 2019
@Centril
Copy link
Contributor

Centril commented Oct 26, 2019

It seems unlikely that we would support this given that we also closed #2617. There also doesn't seem to be any strong support or motivation. Closing therefore.

@Centril Centril closed this as completed Oct 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-control-flow Proposals relating to control flow. A-expressions Term language related proposals & ideas A-syntax Syntax related proposals & ideas T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants