Skip to content

Proposed backward-compatible syntax for owning and output references #1780

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
NXTangl opened this issue Oct 28, 2016 · 1 comment
Closed
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@NXTangl
Copy link

NXTangl commented Oct 28, 2016

Since move is already a keyword, I propose the following:

&move T indicates a move reference to T. A move reference implicitly moves out of whatever it borrows, and dereferencing it consumes the reference, yielding a value of type T, but it may also be borrowed as &T and &mut T. &move T is NOT copy, and does not allow reborrowing like &mut T does. The borrowed variable is considered dropped at the end of the lifetime of the &move T by borrowck. Drop::drop() will be implicitly called.

&move mut T indicases an output reference to T. An output reference is considered an uninitialized variable by the borrowchecker. Only an uninitialized variable can be borrowed as &move mut, and it is considered initialized by borrowck after the end of the lifetime of the &move mut. Once initialized, it is considered identical to &mut T.

&move T is the owning reference that a lot of people have been wanting for a while, and &move mut T is my idea for a generalized placement new syntax, which might be necessary when/if we support unmovable types. An alternative to &move mut T would be a combination of placement syntax and guaranteed return-value optimization for functions returning unmovable types; I suppose the latter would be necessary anyway for them to work at all.

Thoughts? Reasons why this wouldn't actually parse? Alternative syntax?

@sfackler
Copy link
Member

&move has been discussed fairly extensively: see #998 and #1646

@nrc nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label Nov 6, 2016
@NXTangl NXTangl closed this as completed Aug 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

3 participants