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

Move lazy-static.rs out of the nursery? #18

Open
KodrAus opened this issue Apr 29, 2018 · 8 comments
Open

Move lazy-static.rs out of the nursery? #18

KodrAus opened this issue Apr 29, 2018 · 8 comments
Labels
crate Related to a library as opposed to a resource tracking issue

Comments

@KodrAus
Copy link
Collaborator

KodrAus commented Apr 29, 2018

The lazy-static crate is now stable and the nursery doesn't seem like the most appropriate home for it anymore. It's in a similar boat to bitflags.

Should we try find lazy-static a new home under a community GitHub organisation? Has there ever been talk of offering lazy_static as a macro in the standard library?

cc @Kimundi

@KodrAus KodrAus added crate Related to a library as opposed to a resource tracking issue labels Apr 29, 2018
@BurntSushi
Copy link
Member

BurntSushi commented Apr 29, 2018

I've personally always been in favor of putting lazy_static! into std.

It could also move into the rust-lang org, which is where libc and regex live, but the process that established the rust-lang/rust-lang-nursery procedure hasn't really endured (and I think only regex and libc survived it).

@Kimundi
Copy link

Kimundi commented Jun 6, 2018

I'd personally be fine with either.

@AndyGauge
Copy link

So I was digging into this, trying my hand at an RFC to propose the std option so we could get some feedback from a wider audience.

What I don't understand about the option of moving to std involves the no_std implementation of lazy_static. Would the crate lazy_static continue to exist, but only to provide the no_std version and backwards compatibility?

@KodrAus
Copy link
Collaborator Author

KodrAus commented Jul 9, 2018

@AndyGauge Hmm that's an interesting point. The no_std implementation uses the spin crate for synchronization. That's definitely something we could work through in the RFC process.

@vks
Copy link

vks commented Jul 11, 2018

An advantage of moving lazy_static to std (or rather core) would be that no_std could be supported on stable, because the required unstable features can be used for the implementation.

@AndyGauge
Copy link

I've drafted that rfc and really need some help before submitting it. Can you tell me if I'm close here? https://github.com/AndyGauge/rfcs/blob/lazy-static/text/0000-lazy-static.md

@KodrAus
Copy link
Collaborator Author

KodrAus commented Jul 22, 2018

@AndyGauge Sorry, I just got back from vacation. Thanks for taking this on! I see you're getting some traction now on your internals pre RFC. I'll work on catching up with where that conversation is going and see if I can help.

@KodrAus
Copy link
Collaborator Author

KodrAus commented Feb 18, 2019

We spoke about this at the recent All Hands event and at this stage the plan is to shift lazy-static into the rust-lang organization. The driver for this isn't necessarily to bring lazy-static into tighter orbit with the standard library, but more part of an effort to clear libraries out of the nursery.

cc @rust-lang-nursery/libs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate Related to a library as opposed to a resource tracking issue
Projects
None yet
Development

No branches or pull requests

5 participants