Change:
#![feature(integer_atomics)] #![feature(int_roundings)] #![feature(slice_group_by)] <ins> #![feature(split_array)] </ins> #![feature(trusted_random_access)] #![feature(unsize)] #![feature(unzip_option)]

Discussion:
Creating a new issue about const-generic array splitting methods since it's been discussed on the , where it really doesn't belong. We probably want The possibility of a variadic array splitting function was also mentioned (at least that's my interpretation) but since there's not even an active RFC about variadic generics, I think that's a bit out of scope. The only thing one could do once the second above becomes possible is add , and so on.
We also need two or more different use cases.
pointed out that this could be implemented today by taking 2 const params, but the check that they subdivide the array evenly would have to be a runtime assertion. ` We could add the API on nightly with an awareness that we intend to change the API someday.
I made an implementation that errors at compiletime when you specify wrong array lengths! Here a playground link for a PoC:
use case: Parsing binary data into structs that contain fixed-length arrays
I think something that uses traits to impose relational const constraints makes more sense outside of std right now.
yeah, the error message you get when the assert hits is far from pretty and usefull. I'd say its a tradeoff between wanting some ugly compile error whenever the lenghts are wrong, or taking that assertion and finding out the lenghts are wrong during runtime. One thing to make the error a little bit nicer, is to write the following: Now, if somehow the values of , and could be displayed in that message, it would be even nicer
Compile-time errors are better. This means we need to add something to Rust to perform similar static casts in a nicer and shorter way.
Aren't you the same leonardo from the internals forum who created about this exact feature a week ago? I responded there with an explanation of the state of things in regard to that feature. In any event the "correct" API is not to have two parameters and constrain them, but to derive the length of the second array by subtracting the a single parameter from the length of the main array. (). But the current implementation of const generics does not support that. Probably it would be better to hash out what APIs we could implement now, and whether its worth adding them to nightly, in a zulip thread than a GitHub issue.

There I asked for a "where" clause on const integers, while here I've suggested about a more general const_assert that's usable in more/different cases.
Here is an example implementation: (EDIT: Updated features) ()
Is it possible to add now but adjust the signature so that its use is always a compile-time error? I'd like to land the slice version ASAP but I don't want to run into the same problem we had with .
Another use case: converting binary data to integers using
This seems easy: just keep the array version unstable?
This is 100% doable in current nightly rust, in a way that simply results in an immediate compile-time error if an invalid split index is provided, and is also completely -compatible. as a impl of the following trait (which is just a stand-in for the actual type, of course):
To split an array or slice with this functions I'm using: let (a1, rest) = data.splitarrayref::<N(); let (a2, empty) = rest.splitarrayref::<M(); assert!(empty.isempty()); (a1, a2) I guess there isn't a desire for a array method similar to: fn splitintotwoarrays<T, const N: usize, const M: usize(data: &[T; N]) -(&[T; M], &[T; N - M]) {
I think I'd use splitarrayref followed by try_from on the rest.
Check the tracking issue for more details on exact-length splitting for arrays.