Tracking Issue for slice::array_chunks

[lcnr]

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

Also tracks as_(r)chunks(_mut) in #![feature(slice_as_chunks)].

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. Make <[T]>::array_* methods fail to compile on 0 len arrays #99471
• Support calls where N == 0 is unreachable due to conditionals Tracking Issue for slice::array_chunks #74985 (comment)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Iterator vs slices, Does [T]::array_chunks really need to be an iterator? #76354

Implementation history

• implemented in add slice::array_chunks to std #74373
• mut version in Add slice::array_chunks_mut #75021
• as_chunks{_mut} in Add [T]::as_chunks(_mut) #76635
• as_rchunks{_mut} and unchecked versions in Add as_rchunks (and friends) to slices #78818
• const as_(r)chunk in constify slice_as_chunks (unstable) #111453

[joshlf]

Is there any intention of providing the reverse versions of these functions?

[thomcc]

Is there any intention of providing the reverse versions of these functions?

What would that look like?

[joshlf]

Same API, but iterating backwards. I have a use case in which I need to convert either a prefix or a suffix of a slice to an array reference. This API is perfect for the prefix use case, and I'd love to be able to use it for the suffix use case as well.

[newpavlov]

@joshlf
Both slice of arrays and custom iterator type would implement the DoubleEndedIterator, so your use case does not need a separate reverse method.

[joshlf]

That's only true if N evenly divides the length of the slice (see array_chunks docs). Otherwise, the remaining elements are only accessible via the remainder method, and won't be iterated over in the DoubleEndedIterator implementation.

[newpavlov]

Ah, I misunderstood your use case, you want [0, 1, 2, 3, 4, 5, 6] to be split into [4, 5, 6], [1, 2, 3], [0], not into [6], [3, 4, 5], [0, 1, 2]. It indeed requires a separate method.

[joshlf]

Yep, exactly 😃

[thomcc]

Yeah, array_rchunks is definitely worth having.

[sffc]

Also useful would be the inverse operation: [[0, 1, 2], [3, 4, 5]] to [0, 1, 2, 3, 4, 5]. (from &[[T; 3]] to &[T])

[ChayimFriedman2]

Do we need to wait until const_evaluatable_unchecked is stabilized so we can deny N = 0 at compile time to stabilize this feature? Perhaps we can just mention in the documentation that currently it panics but it may be uplifted to a compile time error in the future.

[fzyzcjy]

Hi, is there any alternatives before this is stable? Thanks!

[CryZe]

Hi, is there any alternatives before this is stable? Thanks!

Yeah bytemuck::cast_slice and bytemuck::cast_slice_mut can do mostly the same (with a Pod requirement though)

[fzyzcjy]

Thanks!

[YizhePKU]

I think there should be a safe version of as_chunks_unchecked.

Usually, an "unchecked" version of a function does the same thing as their checked counterpart. Currently, this is not the case.

I propose we rename the current as_chunks_unchecked to as_chucks_exact_unchecked and then add as_chucks_exact.

[c410-f3r]

What is the status of this feature?

[c410-f3r]

Looks like that checking of N == 0 is the only blocker, right? If so, then we probably already have the answer from the responsible party.

• Make <[T]>::array_* methods fail to compile on 0 len arrays #99471
• split_array: remove runtime panics #109049

In other words, it seems that officially runtime checks are preferable over compile-time checks so can we proceed with stabilization?

[jhpratt]

Permitting something to compile knowing with 100% certainty that it will panic seems like an odd decision to make, given that we have the capability to prevent it. Post-monomorphization errors aren't ideal, but surely it's better than an unconditional runtime panic?

[jDomantas]

The problem is that it's not "100% certainty that it will panic". There was an example in another thread (#99471 (comment)) of code that is perfectly legal, but adding post-monomorphization error makes it fail to compile:

fn f<const N: usize>() {
    if N == 0 {
        ...
    } else {
        foo.as_chunks::<N>()...
    }
}

fn main() {
    f::<0>();
}

[jhpratt]

Ah, that makes sense. So unless we can solve the halting problem, a runtime error it is…

[mina86]

If the choice is between stabilising it as is with a runtime error, and keeping it experimental until static if and where N > 0 or N: NonZeroUsize becomes a thing, I vote for keeping this experimental.

[joboet]

I haven't found the time to work on it for the last few weeks, but I think my pre-RFC for pattern types has a good solution for this when combined with rust-lang/project-const-generics#26.

[jhpratt]

Now that inline const is stabilized, we should be able to make compilation fail when N == 0. It's not perfect (as mentioned in #99471, but it would be closer to the desired behavior. Likewise for array_windows (#75027)

[Xiretza]

I think the lang team has made it clear repeatedly that they prefer runtime panics over post-mono errors. Personally I don't agree, but I don't think it's worth arguing over anymore.

[jhpratt]

I don't agree either, but it's also not up to me. This issue has it crossed out, but that doesn't appear to be a formal decision in either direction. The docs currently say

This check will most probably get changed to a compile time error before this method gets stabilized.

So it seems to remain an open question?

[c410-f3r]

A reduced example that should compile according to the responsible team.

pub fn foo<const N: usize>() -> i32 {
    const {
        assert!(N != 0);
    }
    1
}

pub fn bar<const N: usize>() -> i32 {
    if N == 0 {
        2
    } else {
        foo::<N>()
    }
}

fn main() {
    assert_eq!(bar::<0>(), 2);
}

Maybe something about the PR that unblocked inline constants (#122568) could help here?

There are then 4 scenarios for stabilization:

1. Compile-time checks with the current CTFE behavior.
2. Compile-time checks with a machinery that allows the above snippet.
3. Tracking Issue for slice::array_chunks #74985 (comment)
4. Runtime checks, which I also personally disagree.

cc rust-lang/rfcs#3582
cc #122301

[jhpratt]

Thanks for that example. I've added it to the top comment.

[its-the-shrimp]

I haven't seen it discussed here yet, but another way to tackle the case of N == 0 is to not tackle it and just make the iterator return [T; 0] until the end of time, what do you all think about this?

[scottmcm]

and just make the iterator return [T; 0] until the end of time

That would mean the iterator can't be ExactSizeIterator, so I think it's unacceptable.

If people want iter::repeat([]) they should use that; I don' think getting that from array_chunks is ever what anyone calling array_chunks actually wants.

[ais523]

On the subject of the "what should happen if the const argument is 0" debate, I'd like to present what I think is an analogous situation:

fn divide<const D: u32>(n: u32) -> u32 {
    n / D
}

fn divide_checked<const D: u32>(n: u32) -> Option<u32> {
    if D == 0 {
        None
    } else {
        Some(n / D)
    }
}

fn main() {
    dbg!(divide_checked::<5>(99));
    dbg!(divide_checked::<0>(99));
    dbg!(divide::<5>(99));
    dbg!(divide::<0>(99));
}

Playground.

The current behaviour of Rust in this situation is to compile with no errors or warnings (not even on the call to divide::<0>), and to panic at runtime. In other words, if the divisor is coming from a const generic, there's no check for validity, even though division by 0 is always meaningless, and even though divide::<0> always divides by 0 and can easily be observed at compile time to do so.

Meanwhile, if you just write 99/0 directly, you get a deny-by-default lint, unconditional_panic, which makes sense given that the code can never run successfully.

I don't think the situation of, e.g., [T]::as_chunks::<0> is significantly different from that of division by constant zero – nor do I think there would be any particular benefit from making them act differently. I also suspect that there is unlikely to be a better solution than "[T]::as_chunks::<0> panics at runtime if it is ever called, and produces a deny-by-default lint if you write the 0 explicitly, but not if the 0 is calculated based on a constant generic" – this gives the compile-time error we want in the cases where the statement is obviously meaningless, but allows the code to compile in cases where it might not be called due to expanded generic code.

It's also worth noting an edge case:

let fn_pointer = <[u32]>::as_chunks::<0>;

Do we want to allow this, or not? With the explicit ::<0>, I can see a reasonable argument for throwing the unconditional_panic lint, with a message along the lines of "this function pointer will panic if it is ever called". I can't see a use for writing it directly (although I can see how it could potentially happen in expanded generic code, which could end up never calling the function in cases where the parameter is 0).