scottmcm

Given the existing text that > String slices are a UTF-8 representation of characters that have the same layout as slices of type `[u8]`. then I think any concerns I'd...

TBH what I really want for this is a `const Trait`-based approach that's extensible for everyone. I want someone writing a `u256` type to be able to have an automatic-for-the-users...

On suffixes: I think we shouldn't add any more of those, but should instead find a way to make an ascription syntax that people can be happy with. While it's...

I think the core answer here is that there's nothing hashmap-like *as part of the iterator interface*. So it's entirely normal that there's no iterator helpers that really matter for...

> when you want a chain of transforms applied to arrays That wants some form of combinators separated from iterators, though. When it's arrays, you don't want that `.expect` on...

Also, if the use-case is for collecting into arrays, I continue to think that's the wrong abstraction since there's too many error cases to think about and define semantics for....

Beware that appending a file in a loop like that is a [Shlemiel the painter](https://www.joelonsoftware.com/2001/12/11/back-to-basics/) algorithm on Windows (and perhaps others) as the virus scanner will re-scan the whole file...

Should it maybe be `Vec::repeat(n, || whatever)` instead? (Or `from_fn` or `something_with` or whatever) It feels like the `const`-ness here is mostly irrelevant to what this would do, and it'd...

@cuviper Good point! A particularly subtle one is `vec![HashMap::new(); n]`, since that keeps them all from getting different randomstates, whereas `repeat_with(HashMap::new).take(n).collect()` will get `n` different randomstates.

> * It might be easier for the compiler to optimize for the `vec!` version I don't see how, because it's a dynamic length. The implementation is going to be...