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 types with destructors in static variables #1111

Closed
Kimundi opened this issue May 9, 2015 · 12 comments
Closed

Allow types with destructors in static variables #1111

Kimundi opened this issue May 9, 2015 · 12 comments
Labels

Comments

@Kimundi
Copy link
Member

@Kimundi Kimundi commented May 9, 2015

Currently, Rust forbids statics from containing types with destructors:

struct Foo; 
impl Drop for Foo { 
    fn drop(&mut self) {} 
} 
static FOO: Foo = Foo;
error: statics are not allowed to have destructors

This was historically motivated by the question of when to run the destructor:

  • There where worries about supporting life before/after main() for, eg, static variables due to them having historically caused trouble in, eg, C++ code bases.
  • Leaking the destructor was also for the most time not known to be a feasible option due to leaking possibly being bad.

The conservative choice was to forbid such types outright until a decision could be reached.

However, a lot has happened since then:

  • Rusts runtime basically disappeared, with no noteworthy amount of code running before/after main() anymore.
  • With #1066 accepted the language now defines leaking as being safe and allows it in certain circumstances.

Informally, language semantic and idiomatic code now shifted into this position:

  • No user code will run before/after main(), and all initialization/deinitialization needs to happen in it.
  • Leaking destructors is ok if the object lives infinitely long (RC circle, Box<T> -> &'static T)

In keeping with that trend, the language semantic should be changed as follows:

  • It is allowed to store a type with a destructor in a static variable.
  • Values in static variables will never have their destructors run automatically.

The benefit would be more freedom around static variables.

As a concrete use case, this change would allow lazy_static to work without requiring a heap allocation. (It currently uses a raw pointer to a heap allocation in a mutable static to get around the destructor issue)

@scialex
Copy link

@scialex scialex commented May 10, 2015

Another place this would be useful is os Dev. See http://scialex.github.io/reenix.pdf section 3.2.3

Often we have statics that hold global state that would make most sense as maps and the like.

@arielb1
Copy link
Contributor

@arielb1 arielb1 commented May 10, 2015

+1 for this. This shouldn't have soundness implications – you can already get an essentially-equivalent behaviour by rooting your dtor-ey struct in main and never returning (exiting by signal/_exit/exit), which is not particularly non-standard for daemons – but this requires threading a lifetime through everything, which is very ugly.

@pythonesque
Copy link
Contributor

@pythonesque pythonesque commented May 11, 2015

I am generally in favor. My only hesitation is that I vaguely remember finding a way that I would have been able to violate memory safety by abusing the fact that thread locals are 'static if static types with destructors were legal, but I can't actually remember how I was planning to do it, and I may have been mistaken that it was possible.

@arielb1
Copy link
Contributor

@arielb1 arielb1 commented May 12, 2015

@pythonesque

'static thread-locals are not sound anyway in the presence of scoped threads. We essentially need some form of 'thisthread to make them sound.

@rasendubi
Copy link

@rasendubi rasendubi commented Jan 15, 2016

Any update on this?

@golddranks
Copy link

@golddranks golddranks commented Jan 15, 2016

#913 Maybe related.

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Mar 8, 2016

CC @nikomatsakis, could the lang team discuss this and decide? Thanks!

(I’m in favor.)

@thepowersgang
Copy link
Contributor

@thepowersgang thepowersgang commented Mar 8, 2016

#1440 is a draft RFC allowing this, but it may need major revision or rewriting.

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Mar 9, 2016

On Tue, Mar 08, 2016 at 06:16:42AM -0800, Simon Sapin wrote:

CC @nikomatsakis, could the lang team discuss this and decide? Thanks!

I'm roughly in favor. I'll try to take a look at the pending RFC.

@nrc nrc added the T-lang label Aug 30, 2016
@briansmith
Copy link

@briansmith briansmith commented Sep 15, 2016

What is the difference between #1111, #1440, and #913? Since #1440 is merged, can the other two things be closed? If not, why not?

@Kimundi
Copy link
Member Author

@Kimundi Kimundi commented Nov 16, 2016

Indeed, seems like this and #913 can be closed now. I'll update lazy_static to rely on #1440 as a test, then will close.

@Kimundi
Copy link
Member Author

@Kimundi Kimundi commented Nov 19, 2016

Closing after having verified that everything works as expected.

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

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.