????? add slice::array_chunks

[lcnr]

adds a currently somewhat unuseable implementation of #60735.
cc @DutchGhost

I am not sure if this does more harm than good by showing it in the stable docs, but this felt like a nice challenge of my knowledge of the current state of const generics.

r? @varkor for the const generics bit

edit: the biggest problem is #71154, which prevents all uses of slice.array_chunks::<{expr}>() and some type inference stuff which may already be fixed on the currently nightly

[DutchGhost]

Oh! array_chunks, I like that name!

I remember the compiler got a little wonky when array_chunks was a method on [T].

I also remember it was a little less wonky when using a freestanding function as I wrote in #60735 (comment).

Perhaps it's something to investigate if we want this feature to (finally) be usable in nightly?

However I found the free standing function a bit of a downside if it goes for how the resulting code looks at userlevel. <[...]>::array_chunks(slice) vs slice.array_chunks().

[lcnr]

To be fair, the compiler is always a little wonky atm 😆

Free standing functions work as const_chunks_exact::<_, 3> is not a type dependent path,
i.e. we already know which method is used here during ast lowering.

For v.array_chunks, we must know the type of v to get the method definition of array_chunks, and therefore the expected type of 3. This would currently cause a cycle error if we tried to look it up. I tried to explain this problem in more detail in the description of #71154.

<[...]>::array_chunks(slice) also works for methods taking self

[DutchGhost]

Can we make it a method, but enforce function style calling for now? Mainly I find it concerning that when called as method, rustc ICE's. I don't think its good for libcore to have code that crashes rustc when called 'wrong'

[leonardo-m]

Panics if N is 0.

Wish this to happen at compile-time.

[lcnr]

Can we make it a method, but enforce function style calling for now?

Sadly not, as slice.array_chunks::<{expr}>() cases an ice even in cases where slice.array_chunks is invalid (e.g. array chunks is not a method of slice).

So even if we change array_chunks to take slice: &Self instead, we still get the same ICE and also can't use let [a, b] = slice.array_chunks().next().unwrap(); anymore.

[varkor]

I'm going to mark this as a draft for now, because I don't think we're ready to add this even unstably yet, when it's too prone to ICEing. Hopefully we'll be able to get the remaining issues ironed out before too long.

[Muirrum]

@rustbot modify labels to S-waiting-on-author -S-waiting-on-review

[Dylan-DPC-zz]

I'm going to close this. Leaving it open will just accumulate conflicts and things may change in the future. Better to create a new PR when revisiting it.

[lcnr]

Reopened as #74373.