Skip to content
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

Merged
merged 5 commits into from
Jul 2, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions text/0000-const-looping.md
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
Copy link
Contributor

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() in const fn.

be called within constants.

# Motivation
[motivation]: #motivation

Any iteration is expressible as a recursion. Since we already allow recursion
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this hold given recursion depth limits?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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 map, filter, fold even more so (tho combinators have nothing to do with recursion).

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 const fn - feature parity alone and the feeling that the language is uniform when you switch from fn -> const fn should be enough.


# 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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!
Stylistically I'ld do: s/like/like: (and before the other sections as well..)


```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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/BasicBlocks/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,
Copy link
Contributor

Choose a reason for hiding this comment

The 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 #[recursion_limit = "<limit>"] attribute?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's no such attribute

Copy link
Contributor

@Centril Centril Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 Vec.

because we could not guarantee that it'll terminate.

# Drawbacks
[drawbacks]: #drawbacks

* Loops are not guaranteed to terminate
Copy link
Contributor

Choose a reason for hiding this comment

The 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 total effect in the language with a totality checker that guarantees termination.

Copy link
Member

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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