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

Tracking issue for `&mut T` in const fn #57349

Open
ExpHP opened this Issue Jan 5, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@ExpHP
Copy link
Contributor

ExpHP commented Jan 5, 2019

This could be considered a subissue of #24111, however it does not (yet) correspond to a feature in the original RFC, nor does it necessarily correspond to anything that is implemented. It is simply that @Centril suggested I make an issue.


Basically, because &mut references are unique in rust, mutations (except through interior mutability) are not actually observable. Therefore, in theory, it would seem that const fn could support mutation. i.e.:

  • &mut arguments could be accepted
  • locals could be mutably borrowed (&mut expressions)
  • non-initialization assignments could be made (x = y; or *x = y;).

I could not locate any real discussion on this to date.

Presently, we need to discuss whether we want to do this, and if so, what the scope is.

@Centril Centril changed the title Mutation in const fn Tracking issue for `&mut T` in const fn Jan 5, 2019

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 5, 2019

Thanks for filing this issue. :)

  • non-initialization assignments could be made (x = y; or *x = y;).

The first half of this, i.e. x = y, is covered by #48821 which is being stabilized in #57175.

@alercah

This comment has been minimized.

Copy link
Contributor

alercah commented Jan 9, 2019

I could be wrong, but based on previous conversation with @eddyb, this is very much in the plans. They originally wanted to even allow CTFE to mutate statics during the scope of their execution, until it was discussed out that this is undesirable because it would allow a single function call to behave differently depending on whether or not CTFE was used to precompute the function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment