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

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

What would that look like?

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.

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

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.

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.

Yep, exactly 😃

Yeah, array_rchunks is definitely worth having.

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])

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.

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

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)

Thanks!

But panicking on a const generic, in a way that's "well if you ever run the monomorphization you'll see it", is way less of an issue.

That is certainly true in the vacuum. My story gives some perspective on what happens if it becomes a common pattern. The thing is, in that example all relevant values were hard-coded. If they were wrong they'd also always panic. But the issue is we got used to those conversions being the standard so much that a wrong conversion looked like the right one.

To map it to this method, one way this could go wrong is if people indeed started using if N == 0 often they might get so used to it that one day they don't notice that the check is if n == 0 and n is untrusted, so setting it to 0 is a DoS exploit. If used in a nested generic function it'd not emit any warning. And maybe for most, if not all, the people there's a more appropriate solution than doing that check but because the check is easy they weren't force to a more creative/principled solution. Just like we've completely missed that get_array::<const LEN: usize>(offset: usize) -> Option<&[T; LEN]> in an extension trait is possible and a good idea.

I thought the current policy was to always do FCP on the stabilization PR, not the tracking issue?

In this case, I think const-stabilizing these functions will require const-stabilizing an intrinsic (exact_div), which requires t-lang fcp. Preparing the stabilization PR would uncover such points so we don't need to wait for a second round of FCP.

I thought the current policy was to always do FCP on the stabilization PR, not the tracking issue?

It was reconsidered in the last libs-api meeting and decided that if that were to be changed, other related changes would need to be made to facilitate it, such as moving the discussions off of the tracking issues (or some other solution) so that the conversations would not be split between the tracking issue and the stabilization PR. It was mentioned that libs-api had previously done the FCP on the stabilization PR and that the experience was considered to have been a failure, leading to the process of doing it on the tracking issue. So the reasons behind the previous experience of failure with the process need to be explored and the causes resolved.

The divergence in experience is quite interesting, as on the lang side we've found doing the stabilization FCP on the stabilization PR to be a significant process improvement.

In this case, I think const-stabilizing these functions will require const-stabilizing an intrinsic (exact_div), which requires t-lang fcp. Preparing the stabilization PR would uncover such points so we don't need to wait for a second round of FCP.

Agreed. Similarly, apropos of @scottmcm's question, doing it on the stabilization PR helps to make the exact scope of the stabilization more clear.

In this case, I think const-stabilizing these functions will require const-stabilizing an intrinsic (exact_div), which requires t-lang fcp.

On this matter, of course, whoever is handling the stabilization, please put up a PR to stabilize the intrinsics and lang-nominate that. We could make our FCP contingent on libs-api deciding to stabilize the functions here so the FCPs could run in parallel.

@rust-lang/libs-api it would be really good to get clarity on what exact set of functions and types is being proposed for stabilization here, as currently it is unclear.

I put up and FCP for exact_div in #139163 -- I think we might as well just const-stabilize it, because it's not doing anything scary in the first place, and it's not like we can't still delete the intrinsic later if it comes to that anyway.

It was reconsidered in the last libs-api meeting and decided that if that were to be changed, other related changes would need to be made to facilitate it, such as moving the discussions off of the tracking issues (or some other solution) so that the conversations would not be split between the tracking issue and the stabilization PR. It was mentioned that libs-api had previously done the FCP on the stabilization PR and that the experience was considered to have been a failure, leading to the process of doing it on the tracking issue. So the reasons behind the previous experience of failure with the process need to be explored and the causes resolved.

The divergence in experience is quite interesting, as on the lang side we've found doing the stabilization FCP on the stabilization PR to be a significant process improvement.

Yeah that is somewhat surprising. In particular with const stabilization, it can be hard to predict what exactly needs to be stabilized for this to work, such as extra intrinsics or some use of #[rustc_allow_const_fn_unstable]. So even if the FCP happens on the tracking issue, I would recommend a requirement that the stabilization PR must already exist so there is a clear idea of what is being proposed for stabilization.

@rust-lang/libs-api it would be really good to get clarity on what exact set of functions and types is being proposed for stabilization here, as currently it is unclear.

It wasn't discussed in the detail in the meeting, we mostly focused on the N == 0 issue. I'll bring it up again in tomorrow's meeting.

@rfcbot cancel

@Amanieu proposal cancelled.

In the @rust-lang/libs-api meeting today we discussed the specific methods that we are considering stabilizing. We decided to only stabilize the as_chunks methods which return slices and leave the methods returning an iterator as unstable.

Methods being stabilized are:

impl [T] {
    const fn as_chunks<const N: usize>(&self) -> (&[[T; N]], &[T]);
    const fn as_rchunks<const N: usize>(&self) -> (&[T], &[[T; N]]);
    const unsafe fn as_chunks_unchecked<const N: usize>(&self) -> &[[T; N]];
    const fn as_chunks_mut<const N: usize>(&mut self) -> (&mut [[T; N]], &mut [T]);
    const fn as_rchunks_mut<const N: usize>(&mut self) -> (&mut [T], &mut [[T; N]]);
    const unsafe fn as_chunks_unchecked_mut<const N: usize>(&mut self) -> &mut [[T; N]];
}

@rfcbot merge

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

The docs for these functions currently state:

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

That should probably get fixed before stabilization or as part of stabilization.

🔔 This is now entering its final comment period, as per the review above. 🔔

The docs for these functions currently state:

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

That should probably get fixed before stabilization or as part of stabilization.

Couldn't we also remove the panic for these methods and return the entire slice as remainder if N is zero?

Couldn't we also remove the panic for these methods and return the entire slice as remainder if N is zero?

That's possible, but this statement in the docs would have to make an exception on the "strictly less" part:

Splits the slice into a slice of N-element arrays, starting at the beginning of the slice, and a remainder slice with length strictly less than N.

Couldn't we also remove the panic for these methods and return the entire slice as remainder if N is zero?

We could do lots of things, but the big question is whether the alternatives are more useful than they are surprising. Like #74985 (comment) discussed another option above.

In general, I think its good when we panic because something cannot meet the natural post-condition. It's always possible to expand a post-condition to make a panic unnecessary, but that has its own problems when the programmer ends up trying to figure out why something so weird is happening in an edge case rather than getting a really obvious failure from the «sorry, I cannot do that» panic.

Does someone calling .as_chunks() ever want the whole thing to be in the remainder? None of my uses for as_chunks that I can think of ever wanted that. And it breaks the pattern that held for everything else, where as you use a smaller and smaller chunk size the remainder gets shorter and shorter, or where as the input gets longer the remainder gets longer until you fill a chunk and the remainder goes back to zero. Said otherwise, I can't imagine anyone ever calling .as_chunks::<0>() to get that behaviour, and if it happens in generic code it feels more likely that the generic code will do something wrong with the result than be happy with that result -- for example, maybe they notice the input length is longer than the chunk size so of course they can look at the first chunk, but that's not true if it just all got put in the remainder. But we could fix that by returning not (&[], input) but (&[[]; usize::MAX], input)! So would that be better? In some ways I think it is, since now you always have foo.as_chunks::<N>().0.len() >= foo.as_chunks::<N+1>().0.len() again, which is a good property. But is it what people actually want? No, I still don't think it's better than a panic.

It's like how we could say that 0 / 0 is 0 in rust, and that would even be handy for some people sometimes, but we don't and it panics. Or how we could say that indexing has wrapping behaviour, which would be handy for some people sometimes, but we don't and it panics for too-large indices. Or we could have said that 0.ilog2() returns -1 as Self when overflow checking is off, which is in some sense a very natural result, but we didn't and it always panics. Or how originally .step_by(0) repeated the first item forever, but before it was stabilized that was changed, so now that just always panics.

I'd like to note that my request for explaining why take the less conservative approach and which real-world code needs to check N wasn't addressed yet. I don't find the responses so far satisfying because they do not include realistic code which needs the panic rather than compile error.

To put it differently, I don't have a problem with panics if some code actually needs them but I highly doubt there is any such production code. A single example would convince me that panic is better.

But we could fix that by returning not (&[], input) but (&[[]; usize::MAX], input)!

I didn't think about the length of the slice being the (mathematically undefined) dividend – I guess my mind got these methods mixed up with split_first_chunk... please ignore my previous comment.

I'd like to note that #74985 (comment) for explaining why take the less conservative approach and which real-world code needs to check N wasn't addressed yet.

I personally didn't respond because to me, examples aren't what convinces me to prefer panics. Post-mono errors are what convinces me to prefer panics. (Because I think post-mono errors should be avoided at almost all costs.)

I guess my mind got these methods mixed up with split_first_chunk...

I'll just second this point, actually, because I think it's a good one. I used to write .as_chunks().0[0] in examples because there wasn't a .first_chunk().unwrap() so it was by far the easiest way to get an array. But thankfully we have better ways than that horrible snippit now 🙂

the length of the slice being the (mathematically undefined) dividend

A really interesting (but slightly off-topic) thing this makes me think about: Okasaki chapter 9 is about numerical representations, and the equivalence between a way of writing a number and a container of that length. The simplest example is that a linked list is a unary representation of its own length. The book does a neat job of extending that to other things too, like what the container equivalent of a binary number would be -- and how the push/concat implementation on the data structure ends up with the same complexity as the increment/addition operator on a binary number.

So from that perspective, &[T] is a number, and first_chunk is checked_sub on that number, as_chunks is /+% on that number, and as_flattened is *-by-a-constant on it.

A really interesting (but slightly off-topic) thing this makes me think about: Okasaki chapter 9 is about numerical representations, and the equivalence between a way of writing a number and a container of that length. The simplest example is that a linked list is a unary representation of its own length. The book does a neat job of extending that to other things too, like what the container equivalent of a binary number would be -- and how the push/concat implementation on the data structure ends up with the same complexity as the increment/addition operator on a binary number.

So from that perspective, &[T] is a number, and first_chunk is checked_sub on that number, as_chunks is /+% on that number, and as_flattened is *-by-a-constant on it.

This is getting very off-topic, but this equivalence is what I found so incredibly fascinating about lambda calculus. It's taught me that data is defined by how you interact with it – and these interactions are basically nothing but folds.