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!

[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).

[Noratrieb]

The remaining issue here is what to do on as_chunks::<0>(). The current implementation panics, but with inline const it would also be possible to turn it into a post-mono error instead.

#74985 (comment) it is mentioned above that apparently the lang team prefers runtime panics over post-mono errors, but I don't see any links to discussion about this or justification for why. Runtime errors do have the advantage that they won't be triggered in dead code.

The arguments for making it a post-mono error are clear: getting errors earlier (and at all if the code is not tested). Post mono errors won't error in cargo check, but will error in cargo build. Runtime panics won't error in cargo check, won't error in cargo build either, but will only (potentially) error in cargo run/cargo test/cargo oops-its-prod-already.

Other comments above make additional arguments in favor of post-mono errors, and the documentation of the methods also intended to make it a post-mono error eventually.

[traviscross]

@rustbot labels +I-lang-nominated

I'm not sure whether what was mentioned about our lang preferences is actually true, so let's nominate to discuss.

cc @rust-lang/lang

[tgross35]

I don't remember what exactly the argument against post-mono errors was but I do remember thinking "that does makes sense", even though I prefer an earlier error. I want to say @BurntSushi may have originally expressed the concern?

If we do go with the runtime panic, we should document that a future Rust version is allowed to reject N = 0 earlier. (It would be nice if this could be a where N > 0 bound at some point in the future, but that would be more breakage than runtime->post mono).

[cuviper]

I think #74985 (comment) is a good example why a runtime check is desirable, so users can be flexible in their own APIs around this. If I write as_chunks::<N>() where N might be zero in unreachable code, then I don't want an error.

[mina86]

That’s current limitation in expressiveness of the language, no? I can easily imagine:

impl [T] {
    fn as_chunks<const N: NonZeroUsize>() -> (&[[T; N]], &[T]);
}

fn foo<const N: usize>(slice: &[T]) -> Option<i32> {
    let chunks = const if let Some(N) = NonZeroUsize::new(N) {
        slice.as_chunks::<N>().0;
    } else {
        return None;
    };
    todo!()
}

That would require a few things from the language:

• Ability to take non-primitive types as const generic arguments.
• A ‘const if’ construct similar to C++’s ‘if constexpr’.
• An implicit conversion from integer literals to NonZeroX types. (Not strictly necessary but ergonomics would suffer greatly without it).

To me it seems that the question is whether we want to wait for all that or stabilise.

[traviscross]

Maybe neither here nor there, but note that the following works:

const fn divide<const D: u64>(n: u64) -> u64 {
    const { assert!(D > 0) }; // <--- Post-mono assertion.
    n / D
}

const fn divide_checked<const D: u64>(n: u64) -> Option<u64> {
    match D {
        0 => None,
        1.. => Some(divide::<D>(n)),
    }
}

fn main() {
    dbg!({const { divide_checked::<1>(1) }});
    dbg!({const { divide_checked::<0>(1) }}); // <--- Look here.
    dbg!(divide_checked::<1>(1));
}

Playground link

That is, if the function within which we want to compile-time assert is parametric over a type or const generic, is const, and we're always in a const context when we'd see the "bad" generic argument for it, then something like what we want here does work currently.

(The question of whether we'll guarantee to not later disallow this is #122301.)

Interestingly, this is the odd case of a call that we allow in a const context but disallow outside of one.