Tracking Issue for slice::array_windows

[lcnr]

The feature gate for the issue is #![feature(array_windows)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Restrict N to values greater than 0 at compile time instead of using a runtime panic.
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

• implemented in Add array_windows fn #75026

[yoshuawuyts]

In the docs it says:

If N is smaller than the size of the array, it will return no windows.

I'm a bit confused what that refers to; it's the first use of "array" in that section of the docs. Perhaps there's a way to phrase that more clearly?

[lcnr]

@yoshuawuyts see #76827 😆

[leonardo-m]

Is it now possible to forbid N==0 like this?

#![feature(
    const_evaluatable_checked,
    const_generics,
    const_panic,
)]
#![allow(incomplete_features)]

const fn nonzero(n: usize) -> usize {
    assert!(n > 0);
    n
}

fn foo<const N: usize>() -> [u8; nonzero(N)] {
    [0; nonzero(N)]
}

fn main() {
    foo::<5>();
}

[lcnr]

yes, this is possible, it does require us to use `const_evaluatable_checked' in the standard library though.

That's not yet something I feel comfortable with

[the8472]

Bikeshed:

Would windowed_iter() be a better name? It follows the convention that iter() usually returns borrowed iterators.

[TrolledWoods]

@the8472 While it's true that iter usually returns borrowed iterators, there are a lot of borrowed iterators that do not have iter in their name. values, keys, chunks, windows, e.t.c. Considering that windows is already a stabilized name too, it would make sense for this name to also contain windows.

Additionally, if there are any better name suggestions for these const generic equivalents, we need change array_chunks too to follow that convention.

[Stargateur]

Is compile time check of N == 0 a real problem ? I expect LLVM to remove this check for free. The only thing I could think of is we consider it's breaking change to add the compile time check in the future but I hardly can imagine break someone workflow with that, cause it's a hard panic anyway, user code would be considered totally bogus ? But we could decide this stay an assert forever if LLVM optimize it. Maybe replace the panic by an abort ?

Would be amazing to be able to write: const N: NonZeroUsize

[leonardo-m]

Is compile time check of N == 0 a real problem ? I expect LLVM to remove this check for free.

That's beside the point. The point is spotting at compile-time some wrong code.

[Stargateur]

Is compile time check of N == 0 a real problem ? I expect LLVM to remove this check for free.

That's beside the point. The point is spotting at compile-time some wrong code.

I know, of course it would be better, but my point is how many time we need to wait to be able to have this on stable ? const_panic is expected for 1.57 source but const_evaluatable_checked doesn't look stable at all and look really really hard to implement, so I wonder if this would even ever land on stable if we want the compile time check of 0. Thus my though, do we really want this ? It could take years before const_evaluatable_checked is stable it has several ICE issue open. Do we have any clues on #76560 release ?

My point is, could we have the panic (or abort) version and then have the compile time check later ? would we consider it breaking change (I don't know any guideline about breaking change on const generic) ? I just ask open question, I don't really have a strong need or opinion for this anyway. And As I said, could we just... live with it ?

The current main problem of windows is the slice forcing to use try_from or use index, the array_windows is already way better than windows but here we block cause we want the grail by having compile time check of 0 even if current windows also do that and we live with it for years.

[yoshuawuyts]

I used Slice::array_windows for a project yesterday, and it worked really well. I'm excited for this to be stabilized! The only downside is that when we're dealing with streaming data it requires collecting into a vec first.

It'd be neat if once we merge Slice::array_windows, we can look towards adding a variant of Iterator::array_windows as well (example impl). In order for it to have the same yield type as Slice::array_windows we'll first need GATs and lending iterators to land first though; so it'll still be a while longer out. But I hope that once those land we can start experimenting with those.

Examples

Usage example of Slice::array_windows

fn parse1(input: &str) -> usize {
    let lines: Vec<u16> = input.lines().map(|line| line.parse().unwrap()).collect();
    lines.array_windows().filter(|[n1, n2]| n2 > n1).count()
}

Usage example of Iterator::array_windows
This is slightly nicer to use when dealing with streaming data, but requires lending iterators to land in order to have the right return signature.

fn parse1(input: &str) -> usize {
    input
        .lines()
        .map(|line| line.parse::<u16>().unwrap())
        .array_windows()
        .filter(|[n1, n2]| n2 > n1)
        .count()
}

[steffahn]

I'm noticing some missing Send/Sync implementations on the iterator. (Due to the usage of *const T, they are not auto-implemented.)

[clarkmcc]

I'm getting the following error. I'm wondering if it's related to @steffahn's comment, since I can drop-in my own windowing iterator and everything compiles fine.

has type `ArrayWindows<'_, Foobar, 3>` which is not `Send`

[Stargateur]

can't we have a mut version ?

[alexander-novo]

can't we have a mut version ?

Not with the Iterator trait that we currently have in std. With the Iterator trait we currently have, the references we get from calling iter.next() are allowed to outlive the next call to iter.next() - and if we had a mut version, then we could potentially have multiple references to the same item in the slice while one of the was mut - which isn't allowed.

To do this properly, we'd need an iterator which enforces that the references returned by iter.next() can't outlive the next call to iter.next() - which is possible to do, but until recently it wasn't possible to write a trait for that. With GATs stabilized, it's now possible to write such a trait (many people refer to such a trait as a LendingIterator), but no such trait has been written yet for std. Unfortunately, even though GATs are stabilized, there are still many bugs which would prevent people from easily implementing such a trait, and there are also many logistics that need to go into making such a trait useful (i.e. being able to use a LendingIterator everywhere you can use an Iterator). Here's a blog post which goes over some of the details.

[Stargateur]

Indeed this need GATs.

Unfortunately, even though GATs are stabilized, there are still many bugs which would prevent people from easily implementing such a trait

That a bold statement, personally I recently used gat-std work great.