Improve doc on implementing Default

Author: pitdicker

rand_core/src/lib.rs

@@ -91,15 +91,16 @@ pub mod le;
 /// It is recommended that implementations also implement:
 /// 
 /// - `Debug` with a custom implementation which *does not* print any internal
-///   state (at least, [`CryptoRng`]s should not risk leaking state through Debug)
+///   state (at least, [`CryptoRng`]s should not risk leaking state through
+///   `Debug`).
 /// - `Serialize` and `Deserialize` (from Serde), preferably making Serde
-///   support optional at the crate level in PRNG libs
-/// - `Clone` if, and only if, the clone will have identical output to the
-///   original (i.e. all deterministic PRNGs but not external generators)
-/// - *never* implement `Copy` (accidental copies may cause repeated values)
-/// - also *do not* implement `Default`, but instead implement `SeedableRng`
-///   thus allowing use of `rand::NewRng` (which is automatically implemented)
-/// - `Eq` and `PartialEq` could be implemented, but are probably not useful
+///   support optional at the crate level in PRNG libs.
+/// - `Clone`, if possible.
+/// - *never* implement `Copy` (accidental copies may cause repeated values).
+/// - *do not* implement `Default` for pseudorandom generators, but instead
+///   implement [`SeedableRng`], to guide users towards proper seeding.
+///   External / hardware RNGs can choose to implement `Default`.
+/// - `Eq` and `PartialEq` could be implemented, but are probably not useful.
 /// 
 /// # Example
 /// 

src/os.rs

@@ -29,8 +29,8 @@ use rand_core::{RngCore, Error, impls};
 /// machines, it may block very early in the init process, when the OS CSPRNG
 /// has not yet been seeded.
 ///
-/// `OsRng::new()` is guaranteed to be very cheap (after first call), and will
-/// never consume more than one file handle per process.
+/// `OsRng::new()` is guaranteed to be very cheap (after the first succesful
+/// call), and will never consume more than one file handle per process.
 ///
 /// ## Platform sources:
 ///