Proposing lazy_static for the nursery

libs
1

It seems stable, useful and popular. So yeah.

2

I agree that this is quite useful functionality! With the crate today, however, I’ve got a few concerns:

  • Crates which leverage a macro to generate an entire struct/impl block are somewhat unidiomatic in terms of the standard library as it makes documentation for the target difficult to find. An example of this is that the std::thread::LocalKey type is a struct in the standard library and the thread_local! macro just generates an instance of this structure.
  • Unfortunately this crate doesn’t run any destructors, so the globals are always leaked unconditionally. Handling this may require a significant implementation or rethinking what types can be in the globals themselves. In general you don’t need to deallocate statics, but I think this space needs to be explored.
  • Currently the usage of Deref is unidiomatic as all current implementations in the standard library are very small wrappers around shuffling references around. For example there currently isn’t a Deref impl that can panic in the standard library, but this implementation can panic if the initialization expression panics.

Overall I think this sort of functionality would be a good candidate for a nursery crate, but I’d personally prefer to see some of these points addressed first.

1 Like
3

When should destructors be run?

4

In atexit callbacks, presumably.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.