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 locals and destructuring in const fn #2341

Merged
merged 3 commits into from
Mar 7, 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
63 changes: 63 additions & 0 deletions text/0000-const-locals.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
- Feature Name: const_locals
- Start Date: 2018-01-11
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary
[summary]: #summary

Allow `let` bindings in the body of constants and const fns. Additionally enable
destructuring in `let` bindings and const fn arguments.

# Motivation
[motivation]: #motivation

It makes writing const fns much more like writing regular functions and is
not possible right now because the old constant evaluator was a constant folder
that could only process expressions. With the miri const evaluator this feature
exists but is still disallowed.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

`let` bindings in constants and const fn work just like `let` bindings
everywhere else. Historically these did not exist in constants and const fn
Copy link
Contributor

@Centril Centril Feb 20, 2018

Choose a reason for hiding this comment

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

let bindings "everywhere else" (normal fns) introduce bindings which have move semantics when typeof(binding) /: Copy. Does this hold in const fn?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. All code is compiled normally in const fn. The only difference is that the execution is on virtual hardware instead of real hardware. So if your code fails to compile outside of a const environment, it will also fail to compile within a const environment. The reverse does not hold, there's a lot of code that compiles right now that will never compile in a const environment.

Copy link
Contributor

@Centril Centril Feb 20, 2018

Choose a reason for hiding this comment

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

Great 👍. I'd include an explanation of this in the RFC text to make things crystal clear =)

because it would have been very hard to support them in the old const evaluator.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

Expressions like `a + b + c` are already transformed to

```rust
let tmp = a + b;
tmp + c
```

With this RFC we can create bindings ourselves instead of only allowing compiler
generated bindings.

# Drawbacks
[drawbacks]: #drawbacks

You can create mutable locals in constants and then actually modify them. This
has no real impact on the constness, as the mutation happens entirely at compile
time and results in an immutable value.

# Rationale and alternatives
[alternatives]: #alternatives

The backend already supports this 100%. This is essentially just disabling a
check

## Why is this design the best in the space of possible designs?

Being the only design makes it the best design by definition
Copy link
Contributor

Choose a reason for hiding this comment

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

🤣


## What is the impact of not doing this?

Not having locals and destructuring severely limits the functions that can be
turned into const fn and generally leads to unreadable const fns.

# Unresolved questions
[unresolved]: #unresolved-questions