Jack Wrenn

Not sure what to call the `_from_prefix` variant, since `read_from_prefix` is already used, too (except for a visible, not deprecated function).

> * I don't think we need prefix/suffix variants since a reader vends single bytes at a time, and so it can always give us exactly `size_of::()` bytes There's an...

Any updates on this?

We've been blocked for ages on the problem of abstracting over container type. Abstracting over hasher is a much simpler problem and, with type defaults, perhaps even a non-breaking change....

Good catch! This isn't a breaking change since the added fields are private. In theory, we might have users depending on the current unintended behavior. Fortunately, we already having a...

An *advantage* of existential return types is that for itertools adaptors which can be expressed as a composition of other adaptors, we could implement them simply as that composition, and...

I'm not convinced that we should go out of our way to avoid designs that benefit from ample specialization. Specialization is an implementation detail; the API design should be instead...

It's rare that we would need to specialize *every* method of an iterator. For #1046, it probably would have been almost as good to just specialize `fold`, since that would...

> I don't think that includes a trait that does that automatically. No, that's exactly what the initiative provides! It's already available on nightly via the [`TransmuteFrom`](https://doc.rust-lang.org/nightly/std/mem/trait.TransmuteFrom.html) trait. See [this...