Instead of using VecDeque as storage it's also possible to improve performance immensely by just using a bigger Vec and shifting all elements just when it's end is reached. Eg. a Vec with size = window_size * 2 would be a lot more CPU efficient but would just use a bit more memory.
Storage is currently implemented using a Vec as a backing storage. This becomes inefficient for huge window sizes, as the whole array needs to be shifted on every call to next()sometimes.
As noted in #1 it's very hard to implement Storage generically over any container.
One would lose the ability of Window to deref to a (mut) slice.
Window probably has to implement Iterator or Index/IndexMut.
I'd be happy to merge a PR that implements Storage generically over containers if good solutions to the above problems are found and if no functionality gets lost.
Anyway I'd also merge a PR implementing another adaptor, which uses a VecDeque or anything efficient for huge window sizes.