standard lazy types by matklad · Pull Request #2788 · rust-lang/rfcs (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation137 Commits15 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Add support for lazy initialized values to standard library, effectively superseding the popular lazy_static crate.

use std::sync::Lazy;

// BACKTRACE implements Deref<Target = Option<String>> // and is initialized on the first access static BACKTRACE: Lazy<Option> = Lazy::new(|| { std::env::var("RUST_BACKTRACE").ok() });

Rendered

declanvk, pitdicker, SimonSapin, RustyYato, tarcieri, pcpthm, Pauan, VictorKoenders, kgv, F001, and 291 more reacted with thumbs up emoji bl-ue, TennyZhuang, frederikhors, zohnannor, 8573, and bczhc reacted with laugh emoji tarcieri, anp, iago-lito, krircc, mark-i-m, ibkevg, bstrie, forestsia, yoshuawuyts, leoyvens, and 37 more reacted with hooray emoji tarcieri, , DrSensor, anp, Lythenas, nixpulvis, clarfonthey, krircc, jdm, Nashenas88, and 66 more reacted with heart emoji camsteffen, GrayJack, JarvisCraft, dbstratta, bl-ue, schneiderfelipe, DjDeveloperr, TennyZhuang, lmtr0, frederikhors, and 2 more reacted with rocket emoji bl-ue, odboy, frederikhors, and zohnannor reacted with eyes emoji

matklad added T-libs-api

Relevant to the library API team, which will review and decide on the RFC.

A-types-libstd

Proposals & ideas introducing new types to the standard library.

labels

Oct 18, 2019

Centril added A-cell

Proposals relating to interior mutability.

A-sync

Synchronization related proposals & ideas

labels

Oct 18, 2019

Co-Authored-By: Mazdak Farrokhzad twingoow@gmail.com

Great RFC, I hope it makes it into the standard library!

One other aspect that the crate conquer_once tackles is a distinction between blocking and non-blocking methods. I believe this is one possible way to divide the api?

/// Never blocks, returns `None` if uninitialized, or while another thread is initializing the `OnceCell` concurrently.
pub fn get(&self) -> Option<&T>;

/// Never blocks, returns `Err` if initialized, or while another thread is initializing the `OnceCell` concurrently.
pub fn set(&self, value: T) -> Result<(), T>;

/// Blocks if another thread is initializing the `OnceCell` concurrently.
pub fn get_or_init<F>(&self, f: F) -> &T
where
    F: FnOnce() -> T,
;

/// Blocks if another thread is initializing the `OnceCell` concurrently.
pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E>
where
    F: FnOnce() -> Result<T, E>,
;

}

Alternatively, all four methods could be blocking, and a try_get and try_set may suffice for a non-blocking use case.

But don't let this comment derail the discussion about whether to include OnceCell in the standard library to much.

fn pointers are not ZSTs, so we waste one pointer per static lazy value. Lazy locals will generally rely on type-inference and will use more specific closure type.

It looks like rust-lang/rust#63065 will allow using a zero-size closure type in a static:

static FOO: Lazy<Foo, impl FnOnce() -> Foo> = Lazy::new(|| foo());

But this will require spelling the item type twice. Maybe that repetition could be avoided… with a macro… that could be named lazy_static! :)

@SimonSapin or we can add bounds to Lazy like so

struct Lazy<F: FnOnce<()>> { .. }

and use it like this,

static FOO: Lazy<impl FnOnce() -> Foo> = Lazy(foo);

@KrishnaSannasi How does that help with the requirement that static items name their type without inference?

static FOO: &[_] = &[2, 4];

(Playground)

Compiling playground v0.0.1 (/playground) error[E0121]: the type placeholder _ is not allowed within types on item signatures --> src/lib.rs:1:15 | 1 | static FOO: &[_] = &[2, 4]; | ^ not allowed in type signatures

@SimonSapin I'm not sure what you are asking, I didn't use _ anywhere in my example. It would be nice if we could have type inference in static/const that only depended on their declaration, but we don't have that (yet).

You proposed using impl Trait to get rid of the cost of fn() -> ..., and noted a paper cut where you would have to name a type multiple times, and I proposed a way to get rid of that paper cut by changing Lazy by removing the redundant type parameter.

It doesn't really seem all that worth it to me to spend time worrying about how to inline a function that is called at most one time in the entire execution of a program.

RustyYato, pcpthm, kennytm, demurgos, tanriol, withoutboats, luser, JustAPerson, vbfox, AxlLind, and 15 more reacted with thumbs up emoji

A small difference that may be worth noting: std::sync::Once will only run its closure once, while OnceCell::get_or{_try}_init will one run its closure once successfully.

@pitdicker pointed out that we actually can have some part of the sync API exposed via core. This unfortunately increases design/decision space a bit :) I've amended the rfc.

@jhpratt the author of this RFC @matklad is the author of once_cell. It also mentions:

The proposed API is directly copied from once_cell crate.