Jacob Lifshay

it's a constant with known length, I wouldn't consider "computing the length" to be a problem. e.g.: ```rust pub struct Location { pub fn file(&self) -> &'a str { unsafe...

one thing that changes though is that if we get an API to set the implicit `#[track_caller]` argument, that we'd have to pass a `&'static [u8]` in that has both...

if combined with the optimization in `Location`'s size, it's probably smaller to use nul-terminated strings, since each string is only needed for a whole file and only needs one more...

did you also try removing the length field from `Location` at the same time? that may save a lot more space since you'll commonly have many `Location` structs per file...

i don't expect linker deduplication to be able to do much (other than storing each file name once, but I assume rustc can do that itself) since file paths are...

i think you'd also want a `todo_err` or `todo_ok` which is the equivalent of `unwrap_err`

> would allowing unpeeking (thus changing the result of the following `iter.next()`) cause these guarantees to be violated? I don't think so, because doing `*iter.peek_slot() = Some(...)` could be considered...

you could use ChaCha8, which is ChaCha20 but with a lot less rounds: https://en.wikipedia.org/wiki/Salsa20#Reduced-round_ChaCha

another option is using AES-128 in CTR mode, which should be quite fast for the processors that include AES acceleration instructions. it's basically: ```rust struct State(u128, u128); fn aes_128(key: u128,...

something that could be even better than ChaCha8 or AES-128 in CTR mode is to use a [counter-based random number generator](https://en.wikipedia.org/wiki/Counter-based_random_number_generator#CBRNGs_based_on_multiplication) such as the [Squares RNG](https://arxiv.org/abs/2004.06278) -- it has the...