Repository navigation
Tracking Issue for slice_flatten #95629
Description
These methods stabilized in #125561 for rust 1.80 🎉
This issue is now tracking their const-stability.
Feature gate: #![feature(slice_flatten)]
This is a tracking issue for the methods flatten and flatten_mut on [[T; N]], and into_flattened on Vec<[T; N], A>.
Public API
// core::slice
impl<T, const N: usize> [[T; N]] {
pub fn as_flattened(&self) -> &[T];
pub fn as_flattened_mut(&mut self) -> &mut [T];
}
// alloc::vec
impl<T, A: Allocator, const N: usize> Vec<[T; N], A> {
pub fn into_flattened(self) -> Vec<T, A>;
}Steps / History
- Implementation: Add
<[[T; N]]>::flatten{_mut}#95579 - Final comment period (FCP)
- Rename
flatten(_mut)→as_flattened(_mut)#125171 - Stabilization PR Stabilize
slice_flatten#125561 - Stabilize
<[T]>::as_flattenedconst
Unresolved Questions
Are these the best possible names?
Reacted by +merlan #flirora, Demna, Brandon H. Gomes, fwcd, David Hoppenbrouwers, Johannes Dahlström, Tolumide Shopein, Michael Schmidt, Nano, Adam Gausmann and 10 more
Reacted by Michael Schmidt, James C. Wise, Hiro Saito, teor and Friedel Ziegelmayer
Activity
CryZe commentedon Apr 4, 2022
This might pose a similar problem to
array/sliceinto_iterin that array might get a flatten as well, so we may need to be careful when stabilizing this asslice::flatten.Cyborus04 commentedon Apr 4, 2022
Adding
&[[T; M]; N] -> &[T; N * M]would change the type[[1, 2, 3], [4, 5, 6]].flatten()returns, but would that actually be a problem? Anywhere it was expected to be a slice, it could simply deref/coerce into one.wwylele commentedon Apr 4, 2022
I don't think we should rely on coercion for this. In more complicated code that relies on type inference, it might not be able to correctly coerce from array to slice.
I propose we rename this to
flatten_slice, and haveflatten_arrayfor arrayCyborus04 commentedon Apr 4, 2022
Hmm, true.
Another point: the case
[[(); usize::MAX] usize::MAX]would likely turn into a compile-time error rather than a panic, which would technically be a breaking change, if a rather niche one.I like those names, the added explicitness is nice. For the mutable variants,
flatten_slice_mut&flatten_array_mut, orflatten_mut_slice&flatten_mut_array? I prefer theflatten_*_mutones.scottmcm commentedon Apr 8, 2022
We could also use
into_flattenedfor the array version, like we currently have for theVecversion. That way it'd be distinct from the slice versions. Looking at https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv , maybeas_flattened(),as_flattened_mut(), and.into_flattened().That'd also address feedback like #61680 (comment) that calling this
flattenis confusing since it's not exactly the same asIterator::flatten(though I'm not convinced by that concern, personally). And it'd fit with.as_chunks(), which is the inverse method on slices.Cyborus04 commentedon Apr 8, 2022
That would work for
[[T; N]; M]->[T; N * M](indeed, I would like to include that), would it for&[[T; N]; M]->&[T; N * M]?I like that idea, seems more consistent that way
leonardo-m commentedon Apr 15, 2022
A sufficiently common use case I've found for flatten_mut it to reset 2D matrices:
Elarcis commentedon Nov 17, 2022
In the case of generating a flattened slice from an array/vector, I will add a case for
.flat_slice()and.flat_slice_mut()..flatten()which is something I’d expect on iterators, and which works differentlyEdit: or
.as_flat_slice()and.as_flat_mut_slice()for coherence with.as_slice()and.as_mut_slice().Cyborus04 commentedon Nov 26, 2022
That would make the names for equivalent array methods easier too:
.{as_}flat_array(),.{as_}flat_array_ref(), and.{as_}flat_array_mut()mina86 commentedon Dec 17, 2022
Just to stir things up a little, ;) was an alternative/additional
From<&[[T; N]]> for &[T]considered? I think it would solve array problem in the sense that onceFrom<&[[T; N]; M]> for &[T; N*M]andFrom<[[T; N]; M]> for [T; N*M]become possible they could be added as well without having to invent new function name or affecting existing code. Though admittedly usage might be more convoluted in places where type inference cannot help.scottmcm commentedon Dec 17, 2022
@mina86 Personally, the thing I like most about
.flatten()is that it's not so generic. When I call.flatten()I don't need to turbo-fish it, and I know exactly what I'm going to get.With
.into()I might just get the&[[T; N]]back out again unless I'm extra careful. And I also really don't want to type<&[T]>::from(x)most of the time.There's also the potential issue that it can panic when T is a ZST. It's kinda contrived, but generally
Froms try not to do that. (The obvious exception is allocation failure, but that feels pretty different from this O(1) thing.)nvzqz commentedon Aug 9, 2023
I created #114676 but just realized this feature also exists. Perhaps it would make sense to rename this to
flatten_reforflatten_slice?Cyborus04 commentedon Aug 9, 2023
I'm not sure I see why? If to not conflict with
[[T; N]; M] -> [T; N * M], that feature could be namedarray_flatten.66 remaining items
Make slice::as_flattened_mut unstably const
Make slice::as_flattened_mut unstably const
Make slice::as_flattened_mut unstably const
Stabilize const_slice_flatten
Make slice::as_flattened_mut unstably const
Stabilize const_slice_flatten
Make slice::as_flattened_mut unstably const
Stabilize const_slice_flatten
Make slice::as_flattened_mut unstably const
Rollup merge of rust-lang#134927 - DaniPopes:const-as_flattened_mut, …
Stabilize const_slice_flatten
Rollup merge of rust-lang#134995 - DaniPopes:stable-const_slice_flatt…
Stabilize const_slice_flatten
Rollup merge of rust-lang#134995 - DaniPopes:stable-const_slice_flatt…
Stabilize const_slice_flatten