Per dbaupp's comments here, it might make sense to make the AtomicLazyCell<T>: Sync impl T: Sync + Send (possibly the Send impl too?).

@carllerche seeing as you initially wrote the code, and this is a (possibly?) breaking change, thoughts?

To avoid the kind of shenanigans described by dbaupp here, an assert! must be added between the closure call and the LazyCell initialization in borrow_with.

Additionally, a test needs to be added to ensure that a dangling pointer can't be created in this situation.

Is there a safety reason why LazyCell does not implement borrow_mut()? (assuming it'd be on &mut self).

Contrary to its documentation, lazycell::AtomicLazyCell::set can also return an error when the cell is currently being filled by another thread, which means that cell.set(v); cell.borrow() can return None sometimes.

Currently, AtomicLazyCell is missing the borrow_mut, borrow_with, and try_borrow_with functions that LazyCell has. These should be added to ensure we provide a consistent API.

The matrix section of .travis.yml needs to be updated with fast_finish enabled in order to quickly fail builds which fail one of the mandatory builds, without having to wait for the rest.

...
matrix:
  fast_finish: true
...

Since commit fd419de added borrow_mut to LazyCell, would it also make sense to add borrow_mut_with? That seems like the most useful abstraction for using a LazyCell mutably. But maybe there's a subtle soundness issue I'm not thinking of?

Because of PR #60.

Tasks

• Research how to configure Appveyor for rust projects
• Add Appveyor build status badge to README.md

Resources

• azerupi/mdBook - appveyor.yml

Currently, the project does not have a CHANGELOG.md so it is difficult to track changes.

Adding one would greatly help in quickly getting an overview of what changes are brought with each version.

All commits should follow the conventional commit format so that clog-cli can correctly parse them.

Currently we don't specify an ARCH variable so Travis CI only defaults on its default architecture.
If we specify an ARCH variable in the env section, Travis will build on both 64 and 32-bit systems.

See matklad/once_cell#33, I believe this crate has the same issue.

Similar to #79, should LazyCell have a try_borrow_mut_with method as well?

Currently there is no guideline for how to contribute to the project, so a CONTRIBUTING.md should be added to fix this.

Tasks

• Add a CONTRIBUTING.md

Resources

• Rust RFC 1105 - API Evolution
• AngularJS - Git Commit Message Format

Add information on how to utilize this library.
Convert to reference style links.

The date needs to be updated in the src/lib.rs header, as well as in the LICENSE-MIT file.

Currently the clippy service returns a "failed" status, this should be corrected.

A link to the documentation would be a useful shortcut instead of having to check the Cargo.toml.

Currently when we run rustfmt on the code, we use the default rustfmt configuration.
It would be beneficial to define our own rustfmt.toml with our preferred Rust style.

Tasks

• Add rustfmt.toml

Resources

• rustfmt/config.rs
• rust-clippy/rustfmt.toml
• clap-rs/rustfmt.toml

Tasks

• Enable Coveralls travis-cargo check in .travis.yml
• Configure project on coveralls.io
• Add Coveralls badge to README.md

Notices need to be added regarding updating copyright dates as well as adding yourself to the CONTRIBUTORS.md.

Certain sections are unnecessary for the change log so we should remove them.

Currently the include directive in Cargo.toml unnecessarily includes src/*.rs and does not include CHANGELOG.md.

Cargo.toml needs to be updated to include these files.

Cf. that mitochondria commit, in which I remove a &mut T on the stack, which may be put back on the stack by the passed f if OnceCell::init_once is called again reentrantly.

@eddyb also raises the concern that the current code might drop uninitialised memory, because the result of f() isn't first bound to a variable on stack and instead is put directly in the &mut T.

Since commit fd419de, the docs have become inconsistent about whether LazyCell allows mutation. There are several places that claim it's permanently frozen once it's been initialized:

This crate provides a LazyCell struct which acts as a lazily filled Cell, but with frozen contents.

LazyCell: A lazily filled Cell, with frozen contents.

But with that commit, the borrow_mut method now allows it to be mutated, so it doesn't really make sense to describe it as having frozen contents anymore, does it?

That commit also resulted in this pretty confusing sentence:

The limitation of a LazyCell is that after it is initialized and shared, it can be modified.

I can't really figure out what that's trying to say. What does sharing have to do with it, and how is it a limitation to be able to modified?