|
| 1 | +# Rand Documentation |
| 2 | + |
| 3 | +Also see the [main project readme](../README.md). |
| 4 | + |
| 5 | +## Learning Rand |
| 6 | + |
| 7 | +TODO. In the mean-time, we have some learning resources within the API |
| 8 | +documentation. |
| 9 | + |
| 10 | +The following example programs may be of interest: |
| 11 | + |
| 12 | +- [examples/monte-carlo.rs](https://github.com/rust-lang-nursery/rand/blob/master/examples/monte-carlo.rs) |
| 13 | +- [examples/monty-hall.rs](https://github.com/rust-lang-nursery/rand/blob/master/examples/monty-hall.rs) |
| 14 | + |
| 15 | +## References |
| 16 | + |
| 17 | +API documentation can be found: |
| 18 | + |
| 19 | +- [`rand` API on docs.rs](https://docs.rs/rand/) |
| 20 | +- [`rand_core` API on docs.rs](https://docs.rs/rand_core/) |
| 21 | +- [self-published API on github.io](https://rust-lang-nursery.github.io/rand/rand/index.html) (latest code in master branch) |
| 22 | +- by running `cargo doc --no-deps --all --all-features` |
| 23 | + |
| 24 | +## Project policies |
| 25 | + |
| 26 | +### Open Participation |
| 27 | + |
| 28 | +This project is open to contributions from anyone, with the main criteria of |
| 29 | +review being correctness, utility, project scope, and good documentation. Where |
| 30 | +correctness is less obvious (PRNGs and some type-conversion algorithms), |
| 31 | +additional criteria apply (see below). |
| 32 | + |
| 33 | +Additionally we welcome feedback in the form of bug reports, feature requests |
| 34 | +(preferably with motivation and consideration for the scope of the project), |
| 35 | +code reviews, and input on current topics of discussion. |
| 36 | + |
| 37 | +Since we must sometimes reject new features in order to limit the project's |
| 38 | +scope, you may wish to ask first before writing a new feature. |
| 39 | + |
| 40 | +### Stability |
| 41 | + |
| 42 | +TODO |
| 43 | + |
| 44 | +### Project Scope |
| 45 | + |
| 46 | +TODO |
| 47 | + |
| 48 | +### Code style |
| 49 | + |
| 50 | +We do not currently have many policies on style other than: |
| 51 | + |
| 52 | +- neat and consistent |
| 53 | +- minimise changes which are purely stylistic, or move to a separate commit |
| 54 | + |
| 55 | +Rand does **make use of `unsafe`**, both for performance and out of necessity. |
| 56 | +We consider this acceptable so long as correctness is easy to verify. |
| 57 | +In order to make this as simple as possible, |
| 58 | +we prefer that all parameters affecting safety of `unsafe` blocks are checked or |
| 59 | +prepared close to the `unsafe` code, |
| 60 | +and wherever possible within the same function (thus making the function safe). |
| 61 | + |
| 62 | +### New PRNG Algorithms |
| 63 | + |
| 64 | +TODO |
0 commit comments