-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Allow loop
in constant evaluation
#2344
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,98 @@ | ||
- Feature Name: const_looping | ||
- Start Date: 2018-02-18 | ||
- RFC PR: (leave this empty) | ||
- Rust Issue: (leave this empty) | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
Allow the use of `loop`, `while` and `while let` during constant evaluation. | ||
`for` loops are technically allowed, too, but can't be used in practice because | ||
each iteration calls `iterator.next()`, which is not a `const fn` and thus can't | ||
be called within constants. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
Any iteration is expressible as a recursion. Since we already allow recursion | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Small possible improvement: s/a recursion/with recursion. |
||
via const fn and termination of said recursion via `if` or `match`, all code | ||
enabled by const recursion is already legal now. Writing loops with recursion is | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this hold given recursion depth limits? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yea, if the loop takes too many iterations you'll hit the limit, but that's not much of an issue imo, since you can always work around that with unrolling or similar tricks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, thanks for explaining =) Still... might it be good to allow users to raise the limit from the default so that it is not so fixed and so that you can fix cases wherein you know that termination is guaranteed but rustc complains nonetheless? |
||
very tedious and can quickly become unreadable, while regular loops are much | ||
more natural in Rust. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This feels like a somewhat bold assertion that seems to suggest that functional languages are less readable, while I'd argue that the opposite is the case, recursion is often more readable than loops - and iteration combinators using I agree that regular loops are more used in Rust, but I believe this has more to do with the lack of guaranteed TCO (Tail Call Optimization, https://en.wikipedia.org/wiki/Tail_call, https://stackoverflow.com/questions/310974/what-is-tail-call-optimization) which RFC #1888 attempts to address. I don't think any of these assertions are necessary to motivate loops in |
||
|
||
# Guide-level explanation | ||
[guide-level-explanation]: #guide-level-explanation | ||
|
||
If you previously had to write functional code inside constants, you can now | ||
change it to imperative code. For example if you wrote a fibonacci like | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Who doesn't love a fibonacci example =P This section feels very nicely written! |
||
|
||
```rust | ||
const fn fib(n: u128) -> u128 { | ||
match n { | ||
0 => 1, | ||
1 => 1, | ||
n => fib(n - 1) + fib(n + 1) | ||
} | ||
} | ||
``` | ||
|
||
which takes exponential time to compute a fibonacci number, you could have | ||
changed it to the functional loop | ||
|
||
```rust | ||
const fn fib(n: u128) -> u128 { | ||
const fn helper(n: u128, a: u128, b: u128, i: u128) -> u128 { | ||
if i <= n { | ||
helper(n, b, a + b, i + 1) | ||
} else { | ||
b | ||
} | ||
} | ||
helper(n, 1, 1, 2) | ||
} | ||
``` | ||
|
||
but now you can just write it as an imperative loop, which also finishes in | ||
linear time. | ||
|
||
```rust | ||
const fn fib(n: u128) -> u128 { | ||
let mut a = 1; | ||
let mut b = 1; | ||
let mut i = 2; | ||
while i <= n { | ||
let tmp = a + b; | ||
a = b; | ||
b = tmp; | ||
i += 1; | ||
} | ||
b | ||
} | ||
``` | ||
|
||
# Reference-level explanation | ||
[reference-level-explanation]: #reference-level-explanation | ||
|
||
A loop in MIR is a cyclic graph of BasicBlocks. Evaluating such a loop is no | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/BasicBlocks/ |
||
different from evaluating a linear sequence of BasicBlocks, except that | ||
termination is not guaranteed. To ensure that the compiler never hangs | ||
indefinitely, we count the number of terminators processed and once we reach a | ||
fixed limit, we report an error mentioning that we aborted constant evaluation, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps a word about if and how you can control that fixed limit? (I assume the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there's no such attribute There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a different recursion. Recursing in const eval does not actually cause recursion in the compiler, just more elements in the virtual stack |
||
because we could not guarantee that it'll terminate. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
* Loops are not guaranteed to terminate | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nicely written. In the far future it might be interesting to have a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we have a mechanism to adjust the amount of compile-time evaluation allowed, similar to the macro limits? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope, but it's trivial to add (a single line next to the recursion limit attr code) |
||
* We catch this already by having a maximum number of basic blocks that we | ||
can evaluate. | ||
* A guaranteed to terminate, non looping constant might trigger the limit, if it | ||
has too much code. | ||
|
||
# Rationale and alternatives | ||
[alternatives]: #alternatives | ||
|
||
- Do nothing, users can keep using recursion | ||
|
||
# Unresolved questions | ||
[unresolved]: #unresolved-questions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Linking #2237 which (or a modified version of which) will fix that and let you use
iter.next()
inconst fn
.