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

Add scope guards to libstd #9842

Closed
wants to merge 1 commit into from
Closed

Conversation

sfackler
Copy link
Member

This adds a struct which runs a block when it falls out of scope,
similar to scope in D or defer in Go. Using this module directly
requires code to assign the ScopeGuard struct to a variable manually
which is unnecessary in many situations.

It'd be nice to add a syntax extension to automatically expand

scope!(success) {
    ...
}

to something like

let __scope__<FILE>_<LINE>_<COL> = ::std::scope::guard(::std::scope::Success, { ... });

but I don't think that syntax extensions can currently expand to statements as opposed to expressions or items and I'm not familiar enough with libsyntax to add it easily. I put this in libstd instead of libextra since it'll need to be there for the syntax extension to work reasonably.

cc #9835

This adds a struct which runs a block when it falls out of scope,
similar to `scope` in D or `defer` in Go. Using this module directly
requires code to assign the ScopeGuard struct to a variable manually
which is unnecessary in many situations.
@huonw
Copy link
Member

huonw commented Oct 14, 2013

This seems similar to std::unstable::finally.

@sfackler
Copy link
Member Author

It is similar, but provides more functionality. finally could be reimplemented in terms of it or just removed. Should scope live inside of unstable as well?

@thestinger
Copy link
Contributor

I remember @nikomatsakis mentioning something about preventing access to borrowed things in destructors, so it might not be possible to implement this safely without more work on closures (once destructors are sound).

@nikomatsakis
Copy link
Contributor

Destructors should be safe as implemented, but too limiting to express many useful cases. There is a plan to generalize them which I do not think has been fully described anywhere outside the minutes (I'll add it to my todo list). Regardless, I think the plan is to move towards RAII vs closures as much as possible, so as to minimize compilation overhead and expose the control-flow more directly to the compiler for analysis.

@nikomatsakis
Copy link
Contributor

I'll note that with hygiene, I do not believe it is necessary to mangle the name of the variable.

@nikomatsakis
Copy link
Contributor

Ah, I was confused -- I thought the contribution WAS the macro. The code included is not (presently) soundly handled by the borrow checker but it will be after some issues are fixed (#6801, #8861).

@sfackler
Copy link
Member Author

Should this hold off until those issues are resolved?

@sfackler
Copy link
Member Author

Closing this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants